Notación Húngara

[Antonio Linares]

https://bitbucket.org/fivetech/fivewin-contributions/downloads/NotacionHungara.pdf

https://bitbucket.org/fivetech/fivewin-contributions/downloads

Gracias a Charly por recuperarla del baul de los recuerdos

[Antonio Linares]

Y aqui el amigo Simonyi que tuvo hasta el privilegio de viajar al espacio

(quien se lo iba a decir, cuando le daba a la tecla en Microsoft)

[Antonio Linares]

Si alguien más tiene algún documento interesante guardado en el baúl de los recuerdos, que lo comparta que seguro que lo disfrutaremos todos

[elvira]

Maestro,

Muchas gracias por compartir el artículo de Fidonet. En su momento me fue de suma utilidad.

Has pensado en liberar el código fuente de Fivewin 1.0?. Ayudaría mucho para aprender y evitar que se llege a perder

[Antonio Linares]

Elvira,

De momento no he pensado en eso (ni creo que lo llegue a hacer), lo que si tengo organizado es que cuando yo falte, FiveWin esté bien a salvo para que a nadie le pueda afectar y no se pierda nada

Mi deseo era que llegase a ser libre después de que yo no esté (y como diria mi padre, hasta los 140 años), pero mi esposa no está por la labor

Y en cuanto a aprender, a estas alturas todo practicamente está al descubierto. Ya no son los tiempos de Clipper en los que teníamos que armarnos con el debugger a estudiar para aprender. Si no entrego los fuentes al 100% es para que no empiecen a salir infinidad de versiones "inspiradas" en él, pero por lo demás creo que muy pocos productos comerciales ofrecen la libertad que ofrece FiveWin, y a estas alturas se que muchos de vosotros seriais capaces de crear uno vosotros mismos. Valoro más el que estemos unidos, que haya una comunidad de usuarios que se ayuden unos a otros

[elvira]

Entendido una lástima ...

Quizás se podría incluir en la próxima build de FHW solo para usuarios registrados y con prohibición de utilizarlo en ningún caso ??

[cnavarro]

Elvira,

.../...

Y en cuanto a aprender, a estas alturas todo practicamente está al descubierto. Ya no son los tiempos de Clipper en los que teníamos que armarnos con el debugger a estudiar para aprender. Si no entrego los fuentes al 100% es para que no empiecen a salir infinidad de versiones "inspiradas" en él, pero por lo demás creo que muy pocos productos comerciales ofrecen la libertad que ofrece FiveWin, y a estas alturas se que muchos de vosotros seriais capaces de crear uno vosotros mismos. Valoro más el que estemos unidos, que haya una comunidad de usuarios que se ayuden unos a otros

Buenos y entrañables recuerdos ojeando de nuevo el documento.
Me parece perfecta tu visión del tema (ya ha habido bastantes "escisiones" en este mundillo) y es necesario mantenernos unidos todo lo que podamos.

[elvira]

Cristóbal,

Sugerí una liberación reducida, por ejemplo como aliciente además para el próximo build de FWH.

Y a estas alturas no creo que haya más escisiones, porque no hay mercado para más. No hay más que ver como xHarbour.com está cada vez más muerta, y su producto estrella SQLRDD va marchitándose.

Y además lo planteaba para que se anime la comunidad y haya gente de nivel que le pueda venir bien esos conocimientos para hacer nuevos controles, ya que Paco García o Daniel García Gil ya no fabrican más controles desafortunadamente.

Era sólo una idea para revitalizar la comunidad.

[cnavarro]

Cristóbal,

Sugerí una liberación reducida, por ejemplo como aliciente además para el próximo build de FWH.

Y a estas alturas no creo que haya más escisiones, porque no hay mercado para más. No hay más que ver como xHarbour.com está cada vez más muerta, y su producto estrella SQLRDD va marchitándose.

Y además lo planteaba para que se anime la comunidad y haya gente de nivel que le pueda venir bien esos conocimientos para hacer nuevos controles, ya que Paco García o Daniel García Gil ya no fabrican más controles desafortunadamente.

Era sólo una idea para revitalizar la comunidad.

Elvira,
Mis palabras eran en relación a la opinión de Antonio, y, en ningún caso soy quien para valorar las propuestas de ningún compañero, que estoy seguro, llevan la mejor de las intenciones y con el único propósito de vernos potenciados.

Por supuesto que, simplemente, cualquier comentario que aparece en el foro, para mí, es un aliciente para entender que este mundo apasionante en el que nos metimos "hace ya" sigue vivo y con interés e ilusión de mejorarlo.

Ya sé que el mercado no da más de sí (o eso pensamos, ya veremos si podemos apoyar y potenciar adecuadamente Fiveweb, sin olvidarnos de la "joya de la corona" que en mi opinión aún le queda mucha cuerda), era sólo una reflexión, pero algunas veces me ha dado por pensar que hubiese sido de todo ese "mundillo" (no porque lo ponga en diminutivo es lo que significa para mi) si hubiese habido un sólo camino.

Yo hablo desde la perspectiva de haber empezado con Clipper y Fw1.9 y, después de varios años de estar un poco apartado, volver a este tema, que tantas buenas horas y alegrías me ha dado y, encontrarme una situación que no esperaba (no critico, ni valoro, sólo es una reflexión), ya que, si siempre he tenido que defender nuestro lenguaje ante excépticos y "grandes programadores" con "grandes lenguajes", hubiese sido bonito tener una comunidad totalmente unida que nos hubiese dado muchas más alegrías y seguramente un mayor potencial, sin menospreciar, por supuesto, la situación actual.

Creo que para el desarrollo de nuevos controles tenemos suficiente código fuente y ejemplos que estudiar, entre ellos las grandes aportaciones de los "grandes" que has mencionado y otros muchos "grandes" que estoy seguro que sería largo de mencionar y que también han ayudado a llegar aquí. Pero que si por una parte, todos hemos podido usar esas aportaciones, y algunos, para utilizarlos en sus aplicaciones comerciales, por otra, quizás poco ha revertido, al margen de nuestro agradecimiento, a los padres de ello, que tampoco digo que fuese su intención, y tú bien sabes el tiempo que se ha de dedicar para obtener un buen producto (lo mismo que para cualquier componente, sobre todo cuando no programamos para nosotros sino para que nuestra aportación pueda ser utilizada por otros).

Cuando iba a volver a este mundillo, pregunté: "Harbour o XHarbour?" (probé los dos), y obtuve la siguiente respuesta (de Antonio): "Cristobal, usa Harbour", y, con eso me fue suficiente (si el creador de FW, apuesta por Harbour, y voy a seguir usando FW, lo normal es que siga sus indicaciones, no te parece?).

Dicho esto, agradezco tu comentario y como siempre, en lo que pueda humildemente ayudar o apoyar cualquier iniciativa de algún compañero, por aqui seguiré.
Disculpadme por el "rollete"

[thefull]

Buenas a todos

Cuanto tiempo por dios de este escrito, el cual fue fuente de inspiración para mí.
Desde aquí, quiero hacer público mis más enorme agradecimiento por tus escritos, para mí, eres el Asimov de xBase, claro , ameno y conciso, y eso, amigo mío, es MUY DIFÍCIL!

Antonio, esto lo saque de clippermania, de unos TXT que publicaron para poder descargar desde su web todo el contenido, y lo tengo por aquí, con el visor ITACA

Lástima que no tengo el fuente de ITACA, si no, lo montamos con Harbour.

Te pego aqui en formato TXT. Que aproveche

Code: Select all  Expand view

1.- ESTABLEZCAMOS UNAS REGLAS: EL SISTEMA HUNGARO
2.- LOS ARRAYS MULTIDIMENSIONALES EN PROFUNDIDAD
3.- LA UNION PERFECTA: ARRAYS MULTIDIMENSIONALES Y EL PREPROCESADOR
4.- BLOQUES DE CODIGO: QUE SON, COMO SE CONSTRUYEN, PARA QUE SIRVEN
5.- PREPARATE A CAMBIAR TU FORMA DE PENSAR: PROGRAMACION ORIENTADA AL
    OBJETO.


       
1.- ESTABLEZCAMOS UNAS REGLAS: EL SISTEMA HUNGARO.
   
Aunque todos programemos usando el mismo lenguaje, me dar‚is la raz¢n en
que hay grandes diferencias en el estilo de escribir c¢digo de uno a otro
programador. Y esto, desde luego, no es ninguna ventaja. De hecho es un
gran problema.
   
A trav‚s de los art¡culos de esta revista, tendremos ocasi¢n de revisar y
estudiar el c¢digo de muchas funciones, utilidades, etc... Ser¡a una gran
ventaja, que pudi‚semos tomar literalmente el c¢digo de una rutina que nos
interesase y directamente importarla a las l¡neas de nuestro programa.
   
En muchas ocasiones, me ha ocurrido que alguien me ha tra¡do unas rutinas
y me ha pedido que les echase un vistazo, y muchas veces no lo he hecho
porque era francamente dif¡cil entender la organizaci¢n-estructura-ideas
de esas l¡neas de c¢digo. El problema es a£n mayor si se trata de un pro-
grama profesional. ¨Cuantas veces os ha ocurrido que hab‚is retomado el
trabajo de alg£n otro programador, y os ha costado un esfuerzo incre¡ble
entender cada l¡nea de c¢digo? Muchas veces...
   
No se si sabr‚is quien es Charles Simonyi. Es un programador h£ngaro que
ha trabajado (no se si a£n est ) en Microsoft. El invent¢ un sistema de
escribir c¢digo para los programas, y debido a su nacionalidad, sus compa-
¤eros en plan broma le llamaban el m‚todo H£ngaro...
   
Hoy en d¡a es el sistema ESTANDAR que utiliza el 'MicroSoft Aplications
Development Group'. Es decir, ES OBLIGATORIO para los programadores que
trabajan en MicroSoft. El que sus compa¤eros le llamasen el sistema h£nga-
ro, se deb¡a a que a simple vista parec¡a que usaba 'palabras h£ngaras',
por lo raro que se ve¡an...
   
Pero Simonyi, es mucho Simonyi. El m‚todo H£ngaro es realmente potente y
creo que nos vendr¡a a todos muy bien utilizarlo. De entrada, la primera
ventaja que proporciona es que permite a los dem s entender perfectamente
lo que escribimos (o por lo menos lo facilita bastante).
   
Este sistema hemos empezado todos a verlo con el Clipper 5.0, cuando de-
lante de una variable encontramos una letra min£scula (c,n,l,d,a,...) que
indica de que tipo es la variable en uso.
   
Pero el m‚todo h£ngaro es mucho m s potente. Por eso os propongo que estu-
di‚is las ideas que os apunto y que empecemos a usarlas todos. Yo, ya me
lo impuse c¢mo obligatorio. En poco tiempo se notan sus grandes benefi-
cios...
   
1.- Prohibido TERMINANTEMENTE el uso de 'underscores', o sea, de
    E_S_T_O. S¢lo pueden usarse en los defines pero NUNCA en el
    nombre de una variable o funci¢n. En vez de los under_scores
    hemos de usar NoUnderScores. Las partes de una palabra han de
    separarse con may£sculas y min£sculas, NUNCA con UnderScores. OK
    ???

2.- La primera letra de una variable debe indicar el tipo de la
    misma: Tipo esta representado por una letra que indica el tipo de
    variable.
            c, n, l, d, o, a, etc...
   
     cCadena, nNumero, lLogica, dFecha, oObjeto, aArray, etc...
   
3.- Los defines deben empezar por un prefijo (tres letras
    preferentemente) que indiquen que tipo de define es, o a que
    elemento se refieren. S¡ se pueden usar UnderScores. Tambi‚n
    HEMOS DE INDICAR el tipo del define. Esto se hace as¡:
   
             DBF_cNOMBRE
             DBF_nCAMPOS
             KEY_nENTER
             BOX_lOPENED       ¨ Estupendo, no ???
   
4.- Las funciones del SISTEMA, es decir, aquellas que trae el
    lenguaje que usemos de SERIE, se escriben SIEMPRE en min£sculas.
    Sin usar NINGUNA may£scula.
   
    date(), time(), alltrim(), used(), etc...
   
5.- Las funciones que NOSOTROS HAYAMOS CREADO comienzan por
    MAYUSCULAS y pueden usar may£sculas para separar una parte de
    otra.
   
    Aread(), Awrite(), BoxMsg(), etc...
   
    ¨Veis que demasi‚? Si alguno de vosotros publica c¢digo,
    sabremos que funciones son de Clipper y cuales son nuestras...
    Que f cil !!! Si alguien lee c¢digo de otro sabr  r pidamente
    cu les son creaci¢n propia del programador...
   
6.- Las funciones de conversi¢n, es decir, aquellas que pasen de
    un valor a otro, usan el '2' c¢mo separador (se pronuncia two -
    'tu' - 'to' -> 'a' en Espa¤ol).
   
              Str2Arr()
              Hex2Dec()
              Clr2Atr()
   
7.- Las palabras PROCEDURE, FUNCTION y RETURN deben ir SIEMPRE en
    MAYUSCULAS. Y deben ir al mismo nivel de indentaci¢n !!!
   
8.- Con los m‚todos de la programaci¢n orientada al objeto hay una
    excepci¢n. La primera letra del mensaje ser  en MINUSCULAS y las
    dem s partes del nombre del mensaje pueden ir en May£sculas...
   
            oBrowse:addColumn(oCol)
   
9.- OBLIGATORIO: Todos los comandos van en min£sculas !!! La raz¢n es muy
    potente. Los nombres de los campos deben ir en MAYUSCULAS as¡ al ver
    una l¡nea de c¢digo es muy f cil saber sobre qu‚ campos act£a un
    determinado comando. Los nombres de las DBFs y de los CAMPOS van
    siempre en MAYUSCULAS. Los alias tambi‚n van en MAYUSCULAS.
   
10.- OBLIGATORIO: Dejar un espacio entre los par‚ntesis y su contenido.
    Os propongo a todos que lo practiqu‚is. Ver‚is que os gusta mucho, y
    que os va a gustar mucho m s el que pod is entender m s
    f cilmente el c¢digo de los dem s. Me gustar¡a que lo probaseis y
    que deis vuestras opiniones al respecto. ¨OK? ¨Se os ocurren
    m s reglas que puedan mejorar la comprensi¢n del c¢digo? ­Venga, segu-
ro
    que s¡! ¨Que os parece si le ponemos prefijo a las funciones, tambi‚n,
    para saber que es lo que devuelven?
   
    Os adjunto algunas funciones escritas as¡ para que ve is la gran
    diferencia que supone el usar estas t‚cnicas.
   

2.- LOS ARRAYS MULTIDIMENSIONALES EN PROFUNDIDAD.
   
Los Arrays Multidimensionales son la ESTRUCTURA DE DATOS m s importante de
Clipper 5.
   
Todos sab‚is lo que es un Array. Los hab‚is utilizado en Summer 87. ­Aho-
ra, en 5, proporcionan mil veces m s potencia !La primera pega que la
gente me ha comentado acerca de esta nueva forma de arrays es el entender
lo de 'multidimensional'...
   
Si os digo: 'un array de una dimensi¢n... ' lo entend‚is perfectamente.
:-). Si os digo: 'un array de dos dimensiones' tambi‚n me pod‚is seguir...
Si os digo: 'un array de tres dimensiones' m s dif¡cil, pero s¡, s¡ sois
capaces de entenderlo. (Muchos dir‚is, 'si, c¢mo alto, largo y ancho...
tres dimensiones'... ).
   
Vale. Si ahora digo, un array de 4 dimensiones (empiezan las caras raras
:-S ). ¨C¢mo imaginarse cuatro dimensiones?... Y si digo 'arrays de 100
dimensiones' >:-( Tranquilos, que no pasa nada... que no van por ah¡ los
tiros.
   
La primera palabra que confunde es lo de 'dimensional'. Esa palabra no
tiene que ver nada con lo que entendemos por 'dimensi¢n' en el mundo real.
Sencillamente la usamos por tradici¢n, pero no significa nada de eso. No
son dimensiones, como nosotros las entendemos.
   
Hablar de un array multidimensional quiere decir, sencillamente, que algu-
no de sus elementos es a su vez otro array, y puede seguir as¡, sucesiva-
mente, mientras tengamos memoria suficiente. Pero olvidaros de lo de las
dimensiones...
   
Y ¨c¢mo se entiende que un elemento de un array pueda ser a su vez otro
array? Bien. Para eso tendr‚is que armaros de valor :-) y empezar a usar
la palabra 'PUNTERO'.
   
'PUNTERO' quiere decir 'LA DIRECCION DE...'. Si yo os pregunto a cualquie-
ra de vosotros que donde esta vuestra casa, la direcci¢n que me dig is es
UN PUNTERO a vuestra CASA. ¨ok? As¡, si yo quiero ir a buscaros, uso el
PUNTERO que me dice en donde puedo encontraros (vuestra direcci¢n). ¨Me
segu¡s?  Venga...
   
Cuando Clipper monta un ARRAY en memoria, lo pone en alg£n sitio donde le
quepa. Y para no gastar tiempo y energ¡a en moverlo de un lado para otro,
lo que nos da es su direcci¢n, es decir, el lugar en donde el array 'vi-
ve'. ¨ok?
   
Cuando decimos que en un array multidimensional alg£n elemento puede ser
a su vez un array, lo que estamos diciendo es que alg£n elemento contiene
un PUNTERO (la direcci¢n en donde hay otro array en memoria) a otro array.
As¡ que todos los arrays estar n tranquilos en donde est‚n guardados (esto
lo hace Clipper autom ticamente), y manejaremos sus PUNTEROS (sus direc-
ciones).

Todo esto lo hace Clipper por s¡ solo. Sin que nos demos cuenta. Nosotros
sencillamente creemos que los estamos manipulando directamente, pero en
realidad estamos usando sus direcciones (PUNTEROS a los ARRAYS). ¨ M s
claro ahora ?
   
            var1 = { 1, 2, 3 }
   
Clipper sit£a { 1, 2, 3 } en memoria y hace que 'var1' sea un puntero a
dicho array. Si ahora creamos otra variable 'var2' y la hacemos igual a
'var1', lo que estamos es asign ndole la misma direcci¢n que contiene
'var1'.
   
            var1 = { 1, 2, 3 }
            var2 = var1
   
S¢lo hay un array { 1, 2, 3 } y tanto 'var1' c¢mo 'var2' apuntan a ‚l.
Esto lo comprobamos si hacemos ahora:
   
         var1 = NIL      // Estamos borrando la direcci¢n
                         // que conten¡a
   
         ? var2[ 1 ]     // Devuelve 1. El primer elemento
                         // del array
   
Luego el array sigue existiendo aunque variemos 'var1'. ¨cuando Clipper
elimina totalmente el array de memoria? Cuando no exista ning£n PUNTERO a
‚l.
   
      var1 = NIL
      var2 = NIL      // Ahora Clipper SI destruye { 1, 2, 3 }
   
En  realidad Clipper NO TIENE arrays multidimensionales realmente. Lo que
hace es que permite que un elemento de un array sea a su vez un PUNTERO a
otro array que estar  en otra parte de la memoria. Nosotros, como usua-
rios, no notamos nada de esto, el efecto que a nosotros nos produce es que
s¡ existen.
   
Entendiendo esto, veamos ahora cual ser  el comportamiento de Clipper en
la siguiente situaci¢n:
   
          var1 = { 1, 2, { "A", "B", "C" } }
   
El tercer elemento de 'var1' en realidad es un puntero al array { "A",
"B", "C" } que estar  en otra parte en la memoria. Si ahora hacemos,
   
            var2 = var1[ 3 ]
            var1 = NIL
            ? var2[ 1 ]        // Devolver  "A"
   
El array al que apuntaba el tercer elemento de 'var1', sigue existiendo y
su direcci¢n la tiene 'var2'.
   
M s adelante volveremos con todo esto otra vez, porque es fundamental si
queremos sacarle todo la potencia a Clipper 5.

Tambi‚n os ense¤ar‚ algunas funciones muy interesantes. Algunas de ellas
nos permitir n SALVAR un array multidimensional a DISCO y otra funci¢n que
nos permitir  leerlo desde DISCO y restaurarlo en memoria (no importa
cuantas veces est‚ anidado). Mientras tanto, practicad todo lo que pod is,
y recordad: ­­­Equivocarse ayuda a APRENDER!!!



3.- LA UNION PERFECTA: ARRAYS MULTIDIMENSIONALES Y EL PREPROCESADOR.
   
Es f cil usar un array de dos o tres elementos. La mayor¡a de las veces
nos acordamos de memoria de lo que guardamos en cada uno de sus elementos.
Sin problema.
   
Cuando alguno de los elementos de un array es a su vez otro array, la cosa
se va complicando. Tendremos que acudir frecuentemente a donde tengamos
apuntado qu‚ es qu‚. Nos equivocaremos f cilmente...
   
Cuando el array ya llega a dos o tres niveles de profundidad (es decir un
elemento que es a su vez un array, en el que alg£n elemento es a su vez un
array, y as¡ sucesivamente...) dudo que muchos de nosotros seamos capaces
de manejarlo de memoria sin que cometamos errores constantemente. La cabe-
za olvida f cilmente. Y cuando haya pasado alg£n tiempo desde que escriba-
mos el c¢digo, peor que peor.
   
Pero, tranquilos. Tenemos el aliado perfecto:  EL PREPROCESADOR. El pre-
procesador nos permitir  hacer verdaderas virguer¡as con los arrays multi-
dimensionales y os aseguro que con la t‚cnica que voy a explicaros NO
COMETEREIS NI UN ERROR !!!
   
No pens‚is que es tan f cil c¢mo cre‚is. De hecho, yo pas‚ mucho tiempo
probando y probando, hasta que di con el truco...
   
Existen unas reglas de ORO que ten‚is que usar para que manipular ARRAYS
MULTIDIMENSIONALES, AL NIVEL QUE SEA, sea un juego de ni¤os. Tambi‚n vamos
a ver COMO LEERLOS. No se trata s¢lo de escribirlos, se trata de entender
luego lo que pongamos !!!
   
El preprocesador tiene la sentencia #define que nos permite sustituir una
expresi¢n por otra ANTES de que el compilador haga su trabajo. Imaginad
que tenemos un array de 3 elementos:
   
            aArray = { "A", "B", "C" }
   
Ahora supongamos que para evitarnos recordar lo que significa cada elemen-
to usamos los siguientes #defines:
   
       #define PRIMERO 1
       #define SEGUNDO 2
       #define TERCERO 3
   
Podemos sustituir los ¡ndices a usar por esos 'defines' con lo que todo
ser  mucho m s f cil:
   
          ? aArray[ PRIMERO ]
          ? aArray[ SEGUNDO ]
          ? aArray[ TERCERO ]
   
Vale. Pero... supongamos ahora que en el primer elemento de este array
queremos crear otro array de tres elementos en el que vamos a guardar tres
expresiones de color (en el formato corriente):
   
           aArray[ PRIMERO ] = array( 3 )
   
Podemos pensar en volver a usar esos mismos defines, pero ver‚is que empe-
zamos a liarnos:
   
           aArray[ PRIMERO ][ PRIMERO ] = "B/W"
           aArray[ PRIMERO ][ SEGUNDO ] = "GR+/B"
           aArray[ PRIMERO ][ TERCERO ] = "BG+/R"
   
En vez de eso, probemos lo siguiente. C¢mo sabemos que queremos guardar en
el primer elemento un array de colores, en vez de usar #define PRIMERO 1,
usaremos
   
         #define aCOLORES 1
   
Ahora, crearemos otros defines para manipular los elementos de este array:
   
         #define CLR_cNORMAL  1
         #define CLR_cINVERSO 2
         #define CLR_cBORDE   3
   
     Fijaros en c¢mo queda ahora:
   
         aArray[ aCOLORES ][ CLR_cNORMAL ] = "B/W"
         aArray[ aCOLORES ][ CLR_cINVERSO ] = "GR+/B"
         aArray[ aCOLORES ][ CLR_cBORDE ]  = "BG+/R"
   
M s dif¡cil todav¡a. Supongamos que ahora queremos que el elemento
aArray[ aCOLORES ][ CLR_cBORDE ] sea a su vez otro array que guarde los
distintos tipos de color para bordes que vayamos a utilizar:
   
         aArray[ aCOLORES ][ CLR_cNORMAL ] = "B/W"
         aArray[ aCOLORES ][ CLR_cINVERSO ] = "GR+/B"
         aArray[ aCOLORES ][ CLR_aBORDE ]  = "BG+/R"
   
         aArray[ aCOLORES ][ CLR_aBORDE ][ BRD_cUNO ] = "BG+/R"
         aArray[ aCOLORES ][ CLR_aBORDE ][ BRD_cDOS ] = "RB+/B"
         aArray[ aCOLORES ][ CLR_aBORDE ][ BRD_cTRES ] = "RB+/B"
   
¨Os dais cuenta que es f cil? Ya nos estamos manejando a tres niveles y
nos es dif¡cil... podemos seguir as¡ sin problema.
   
     Os resumo las reglas a seguir:
   
- El nombre del DEFINE consta de un PREFIJO y de un SUFIJO.
   
- El PREFIJO constar  de TRES LETRAS. Esas tres letras representan el
  nombre de lo que estemos usando. Si, por ejemplo, vamos a crear unos
  DEFINES para  guardar los valores de determinadas pulsaciones, usaremos
  KEY_ de 'tecla' en Ingl‚s, o si prefer¡s TCL_ de 'tecla'. Por lo general
  se usan las CONSONANTES del nombre a escribir, suprimiendo las VOCALES
  TeCLa. ¨ OK ?
   
- Entre PREFIJO y SUFIJO situaremos un UNDERSCORE '_' (mucha palabra para
  tan poco :-) ¨no?). En Espa¤ol: Un 'SUBRAYADO'.
   
- A continuaci¢n, y en min£sculas, escribiremos ( siguiendo el METODO
  HUNGARO ) una letra en MINUSCULAS que represente el tipo que tiene el
  valor que vamos a substituir. Ojo, con esto. Tenemos DOS alternativas,
  o poner el tipo del elemento a SUSTITUIR (aCOLORES, Un array) o poner el
  tipo del elemento sustituido (nCOLORES, pues nCOLORES es 3). Seg£n la
  situaci¢n usaremos una forma u otra. Yo prefiero la PRIMERA. Es mil
veces
  m s intuitiva, pero... lo mejor, SIEMPRE, ser  lo m s pr ctico.
   
- A continuaci¢n va el SUFIJO. El SUFIJO representa la CARACTERISTICA o el
  DATO del PREFIJO que estemos utilizando. As¡, en  CLR_cNORMAL, NORMAL es
  de tipo 'c' y es el COLOR (CLR) 'NORMAL'.
   
- IMPORTANTISIMO: SUFIJO y PREFIJO en ELEMENTOS CONTIGUOS del array deben
  COINCIDIR (o ser pr cticamente la MISMA PALABRA, aunque abreviada). Esta
  es LA FORMA DE COMPROBAR QUE NO NOS HEMOS EQUIVOCADO AL USAR EL ARRAY
  MULTIDIMENSIONAL.
       
- Si un SUFIJO termina en S (una 'ese'), quiere decir que hay m s de un
  elemento de ese tipo (por estar en plural) y entonces, el siguiente
  elemento debe indicar CUAL de los elementos es:
   
    aArray[ aPANTALLA ][ PNT_aCOLORES ][ CLR_aNORMAL ][ NRM_cTINTA ]
   
  Fijaros (es importante) que para saber si esta expresi¢n est  bien
  escrita o no, lo que hacemos es comparar los PREFIJOS CON LOS SUFIJOS
  anteriores:
   
               aPANTALLA ... PNT  ( PaNTalla )
               aCOLORES......CLR  ( CoLoRes )
               aNORMAL.......NRM  ( NoRMal )
               etc...
   
  Si existe esta correlaci¢n entre SUFIJOS y PREFIJOS, entonces es que
est 
  bien escrito. SIN ERRORES !!!
   
- C¢mo se lee un array multidimensional escrito con estas normas:
   
     El del ejemplo anterior:
   
    aArray[ aPANTALLA ][ PNT_aCOLORES ][ CLR_aNORMAL ][ NRM_cTINTA ]

   
  La TINTA del COLOR NORMAL de los COLORES de la PANTALLA. M s o menos, lo
  que se hace es leerlo de DERECHA a IZQUIERDA. Contra m s practiqu‚is,
m s
  f cil se os har . Si SUFIJOS y PREFIJOS coinciden, entonces est  bien
  escrito.
   
  Recordad que si un SUFIJO termina en 'S' es que representa a un elemento
  que consta de varios, as¡, en un bucle prestad atenci¢n:
   
        FOR nCual = 1 TO 10
   
          aColor = aArray[ aPANTALLA ][ PNT_aCOLORES ][ nCual ]
          ...
        NEXT
   
La clave: Pr ctica... mucha pr ctica. :-) . Espero que os haya gustado. Ya
ver‚is c¢mo los us is con toda confianza.
   

4.- BLOQUES DE CODIGO: QUE SON, COMO SE CONSTRUYEN, PARA QUE SIRVEN.
   
He le¡do bastantes definiciones de 'bloque de c¢digo'. Ninguna me ha gus-
tado. :-( . De por s¡, el hablar de 'bloque de c¢digo' resulta lioso, pero
si encima alguien viene y nos dice que es 'un nuevo tipo de dato', peor
que peor... :-)
   
¨Que hay de nuevo y que hay de viejo en los 'bloques de c¢digo'? Antes que
nada deciros que los 'bloques de c¢digo' NO  son un 'invento' de
Nantucket. Los 'bloques de c¢digo' existen desde hace mucho tiempo en
otros lenguajes... lo que pasa es que  nadie les llamaba as¡.
   
Hemos de armarnos de valor y volver a usar la palabra 'PUNTERO'. Hemos
visto que un 'PUNTERO' es la direcci¢n en memoria en donde hay algo deter-
minado. Es la 'direcci¢n' en donde ese 'algo' est .
   
Al aprender a programar en C, se suelen pasar malos ratos intentando 'ha-
cerse' con los PUNTEROS. Pero entenderlos a fondo es muy importante. Fija-
ros si son importantes, que ahora Nantucket nos los pone cada vez m s en
Clipper.
   
Hemos visto que cuando usamos un ARRAY, Clipper lo sit£a en alg£n lugar de
la memoria del ordenador y que para no estar movi‚ndolos de un lado a otro
(pues pueden ser muy grandes y adem s resultar¡a muy lento), nos propor-
ciona un PUNTERO (la direcci¢n) a su posici¢n en memoria.
   
Del mismo modo que una variable (¢ un ARRAY) est  situada en alg£n lugar
de la memoria de nuestro ordenador, cuando el enlazador termina de cons-
truir el EXE, ha situado en determinadas partes del EXE a los diferentes
'trozos' de nuestro programa ('bloques de c¢digo').
   
Un bloque de c¢digo lo que hace es situar en alg£n lugar de la memoria una
serie de instrucciones a ejecutarse m s tarde, y lo que hace es DEVOLVER
UN PUNTERO al lugar de la memoria en donde ha situado ese conjunto de
instrucciones.
   
Cuando hacemos un EVAL( bVARIABLE ), lo que hacemos es decirle al programa
que 'salte' a esa direcci¢n y que ejecute lo que hay all¡. ¨ Lo entend‚is
mejor ahora? Espero que s¡...
   
Esos PUNTEROS se guardan en variables que pasan a ser de tipo 'b' (bloque
de c¢digo). En realidad esas variables 'valen' un n£mero que indica una
direcci¢n en memoria. Estos valores son bastante delicados, por lo que
Nantucket no nos deja que los manipulemos alegremente pues provocar¡amos
el CUELGUE DEL SISTEMA si le dij‚semos a nuestro programa que 'saltase' a
una parte de la memoria en donde no hubiese c¢digo sino cualquier otra
cosa.

Esta es la raz¢n por la que no podemos salvar el valor de un bloque de
c¢digo a disco ni a un archivo. Estas direcciones variar n de un programa
a otro, de un estado del sistema a otro.
   
Luego, ¨que es un bloque de c¢digo? Es un PUNTERO a un lugar de la memoria
en donde se encuentran una serie de INSTRUCCIONES listas (ya est n compi-
ladas) para funcionar. ¨ok?
   
En C, por ejemplo, un 'bloque de c¢digo' se representa por el NOMBRE de la
FUNCION sin usar los PARENTESIS. O sea, que si tenemos la funci¢n (en C)
PRINTF(), el nombre 'PRINTF' es el PUNTERO a PRINTF(). Cuando le digamos
al programa que salte a donde apunta 'PRINTF', saltaremos a donde est 
PRINTF(). Es c¢mo si hici‚semos en Clipper EVAL( PRINTF ). Espero no lia-
ros :-). ­Seguro que no !
   
Bueno, vamos a lo siguiente. ¨C¢mo se escribe un bloque de c¢digo?
   
Un bloque de c¢digo es una 'FUNCION SIN NOMBRE'. Lo vais a ver en este
ejemplo:
   
     FUNCTION PRUEBA( nValor1, nValor2 )
   
      tone( nValor1, nValor2 )
   
     RETURN "Ya est "
   
Fijaros ahora en c¢mo escribir¡amos esa misma funci¢n, pero cre ndola c¢mo
un bloque de c¢digo:
   
      { | nValor1, nValor2 | tone( nValor1, nValor2 ), "Ya est " }
   
Es exactamente igual que la funci¢n que escribimos antes. La funci¢n
PRUEBA(). Lo que ocurre es que ahora el nombre 'PRUEBA' no aparece por
ninguna parte. ¨Comprend‚is porque se les dice a los 'bloques de c¢digo'
que son funciones sin nombre?
   
Los nombres que aparecen entre las barras verticales son los par metros de
esa funci¢n. Al igual que en una funci¢n tradicional, esos nombres pueden
ser lo que nosotros queramos, en general usaremos los nombres que m s nos
recuerden lo que estamos haciendo. Mucha gente cuando ve bloques de c¢digo
anda como loca buscando por el resto del programa los nombres que ah¡
aparecen entre barras verticales. Y pueden no estar en ninguna otra parte.
Es exactamente igual que hacemos al definir los nombres de los par metros
a una funci¢n ¨ok?
   
Las l¡neas que ten¡a la funci¢n PRUEBA(), ahora se escriben separadas por
comas. As¡ de f cil. Y... la £ltima expresi¢n que aparece en el bloque de
c¢digo es lo que devolver  el bloque de c¢digo al ejecutarse, ­­­ IGUAL
QUE EL RETURN DE UNA FUNCION !!! ( "Ya est " en nuestro ejemplo ).
   
No pretendo con est s l¡neas que se is unos maestros de los bloques de
c¢digo. Pero le‚roslas varias veces, consultad el manual y practicad. Es
bien f cil (cuando se entiende :-)).
   
¨ Y para que sirve un bloque de c¢digo ?
   
C¢mo os coment‚ antes, los programadores en C hace mucho tiempo que tienen
'bloques de c¢digo' y os dir‚ que muchos de los programadores en C que
conozco, NO LOS USAN para nada ni tienen mucha idea de para que sirven.
Esa es una de las cosas que m s me gusta de Clipper, que es la mejor 'aca-
demia' de programaci¢n que he conocido :-). Curiosamente... la programa-
ci¢n orientada al objeto tiene su fundamento en los punteros a funciones
en casi un 90 % de su dise¤o...
   
Os voy a decir algo 'muy fuerte'. Agarraros...
   
Igual que los PARAMETROS de una FUNCION modifican el RESULTADO de esa
FUNCION, un BLOQUE DE CODIGO modifica la LOGICA de UNA FUNCION. La FUNCION
se COMPORTARA de un MODO DISTINTO si en su 'maquinaria' EVAL()UA determi-
nados bloques de c¢digo que PUEDEN SER DISTINTOS de una vez para otra.
Tiempo al tiempo... Esto no es llegar y topar...
   
Mucha gente que ya usa los bloques de c¢digo en Clipper, los usa m s que
nada para escribir menos l¡neas de c¢digo. Pero este no es su principal
fin. Fundamentalmente sirven para hacer que algo (una funci¢n o un objeto)
'razonen' de otra manera. Que modifiquen su l¢gica. Eh !Seguid leyendo! No
os vay is !Prometo no volver a decir m s cosas as¡! :-)
   
Volveremos a verlos. Veremos muchos ejemplos. Es f cil, de verdad. Lo
importante es que le is esto algunas veces y que por lo menos 'os lo se-
p is de memoria' :-).

   
5.- PREPARATE A CAMBIAR TU FORMA DE PENSAR: PROGRAMACION ORIENTADA AL
    OBJETO.
   
Tened por seguro que en el futuro m s inmediato, nos VAMOS A HINCHAR de
usar la PROGRAMACION ORIENTADA AL OBJETO. Dentro de poco, Nantucket sacar 
una nueva versi¢n de Clipper (no me refiero a la 5.01, sino a la 5.02 o a
la 5.05 o a la 6.0), y esa nueva versi¢n va a ser un 'recital' de
PROGRAMACION ORIENTADA AL OBJETO.
   
En serio, el OOPS (Object Oriented Programming System) es TREMENDAMENTE
IMPORTANTE, IMPORTANTISIMO, as¡ que cuanto antes empecemos a entenderlo
bien, mucho mejor. Vamos a empezar a ver, paso a paso, cada secreto del
OOPS. :-)
   
¨ Porqu‚ aparece el OOPS? ¨De donde viene? ¨Para que sirve?
   
Supongo que todos los que est is leyendo esto, sab‚is perfectamente lo
importante que es la PROGRAMACION ESTRUCTURADA. El lenguaje 'maestro' en
programaci¢n ESTRUCTURADA es el C, y la estrella fundamental es 'LA
FUNCION' (funciones estandar y UDFs). Todo esto lo tiene muy claro Clipper
y por eso cada vez nos acercamos al C m s y m s.
   
La idea de la programaci¢n estructurada es REUTILIZAR NUESTRO ESFUERZO y
ganar en SIMPLICIDAD. Cuando pasamos varias horas escribiendo una funci¢n,
y al final conseguimos que haga lo que queremos, la guardamos en una li-
brer¡a y ya no nos volveremos a preocupar de c¢mo funciona, la utilizare-
mos y ya est . (por cierto, os supongo a todos 'maestros' en
construir-manejar-estudiar-investigar-desarrollar librer¡as, sino es as¡,
podemos dedicarle un estudio a fondo al tema, ­dec¡dmelo!).
   
En nuestra mente ganamos en SIMPLICIDAD. Ya no tendremos que volver a
pensar en el mecanismo de esa FUNCION que hemos escrito. En el futuro,
REUTILIZAREMOS NUESTRO ESFUERZO. ( a esto se le llama 'reusabilidad del
c¢digo').
   
La programaci¢n TRADICIONAL pensaba que esto era lo m ximo en
ESTRUCTURACION. Pero hay muchos genios sueltos por ah¡... :-)
   
Fijaros en este detalle. Una FUNCION suele COMPORTARSE de distinta FORMA
seg£n los PARAMETROS (los DATOS) que le PROPORCIONEMOS. Y a la vez, la
tarea habitual de una FUNCION suele ser MODIFICAR determinados DATOS...
¨Veis que fuertemente relacionados est n los DATOS y las FUNCIONES?
   
Los estudiosos de la PROGRAMACION, se dieron cuenta de esta ¡ntima rela-
ci¢n entre DATOS y FUNCIONES. Y sencillamente se dijeron '¨PORQUE NO
DESARROLLAMOS UNA ESTRUCTURA EN LA QUE DATOS Y FUNCIONES ESTEN JUNTOS?'
ASI CONSEGUIREMOS UNA MAYOR ESTRUCTURACION EN NUESTROS PROGRAMAS, ES
EVIDENTE. Y as¡, es como nacen los OBJETOS... (tachan !!!), las CLASES, el
OOPS...

Luego, el primer OBJETIVO del OOPS es ganar en ESTRUCTURACION. Es decir,
hacer que el desarrollo de nuestros programas sea MAS FACIL, que se
REUTILICE mucho m s nuestro ESFUERZO, y que tengamos que 'mantener' menos
cosas en la cabeza. De hecho, el creador del C++ (C con CLASES), afirm¢
que un programador que utilice OOPS puede escribir, ‚l solo, un programa
de 25.000 l¡neas de c¢digo sin gran esfuerzo !!! Cometer  muy pocos erro-
res  !!! Y , en todo momento, mantendr  la ESTRUCTURA del programa en su
cabeza... ¨¨¨A que os est  interesando la programaci¢n orientada al objeto
cada vez m s??? :-)
   
Bien, sigamos...
   
Existen otras razones por las que resulta evidente que podemos ser MEJORES
PROGRAMADORES usando OOPS. Ve moslas paso a paso:
   
Hemos visto que el objetivo que el desarrollo del OOPS se propon¡a era el
AGRUPAR DATOS y FUNCIONES (veremos que a esto se le dice 'ENCAPSULACION').
Pero es que se dieron cuenta que lo que resultaba de agrupar DATOS y
FUNCIONES se parec¡a a algo... ¨A que se parece? :-)
   
Fijaros en cualquier OBJETO de los que haya en la MESA m s cercana a voso-
tros, ¢ en esa estanter¡a, da igual... s¡, un OBJETO cualquiera. ¨Lo ha-
b‚is elegido ya? Yo, por ejemplo, tengo ahora aqu¡ a mi lado un VASO de
CRISTAL. Lo que os voy a contar de ‚l sirve tambi‚n (comprobadlo) con ese
OBJETO que hay is elegido.
   
¨ Que es un VASO DE CRISTAL ? Un VASO DE CRISTAL es 'algo' que tiene una
serie de DATOS caracter¡sticos y que se comporta de unas determinadas
formas (METODOS) ante determinadas circunstancias (MENSAJES).
   
¨Cuales son los DATOS DE UN VASO DE CRISTAL? Pues, es de cristal, es tran-
sparente, mide unos 15 cms. de alto, pesar  unos ciento y pico gramos,
tiene una forma caracter¡stica, un color determinado (aunque sea transpa-
rente puede tener un determinado color, no? ), tiene algunos dibujos ta-
llados, tiene una cavidad que es en donde puede contener l¡quido, etc...
   
Y ¨QUE SABE HACER UN VASO? Pues varias cosas... Sabe CONTENER EL LIQUIDO
si DECIDIMOS LLENARLO. Rueda si lo empujamos, se rompe si lo hacemos caer
desde alto, etc...
 
Fijaros que parecido es un OBJETO de la naturaleza a lo que nosotros nos
propon¡amos al ESTRUCTURAR CONJUNTAMENTE DATOS Y FUNCIONES. Que curioso...
   
Pero es que a£n hay muchas m s coincidencias y curiosidades...
   
¨Hace cuanto tiempo que sois programadores? ¨4, 5, 8, 10 a¤os? ¨desde hace
cuanto tiempo utiliz is al 100% las t‚cnicas de programaci¢n estructurada?
(No me mint is, eh!), 3, 4, 5  a¤os, ¨un poco m s quiz ?... :-)
   
Daros cuenta de esto. Desde que todos nosotros ERAMOS BEBES (si BEBES, con
pa¤ales, cunas, papillas, etc... :-) ), hemos estado USANDO OBJETOS. Lle-
vamos practicando TODA NUESTRA VIDA. Todos nosotros SOMOS MAESTROS en el
uso y convivencia con los OBJETOS. Hay un MUNDO DE OBJETOS a nuestro alre-
dedor desde SIEMPRE...!!!
   
De hecho, nuestro sistema nervioso (s¡, ese que se altera cuando no apare-
ce un bug :-) ) sabe la importancia de todo esto, y  nuestra mente, gene-
raci¢n  tras  generaci¢n,  ha ido desarrollando extraordinarias capacita-
ciones en el uso de los objetos, para tener control en el mundo que nos
rodea. (Dir‚is que me he vuelto chalado, que tiene que ver todo esto con
  Clipper,... ya ver‚is que mucho m s de lo que pod is pensar ahora...
:-)).
   
Una de las facultades del ordenador m s incre¡ble que existe (no, no me
refiero al 486... sino al cerebro humano) es la capacidad de ABSTRACCION.
De un mundo en que s¢lo existe lo PARTICULAR, nuestra mente crea lo
GENERAL. Gracias a la ABSTRACCION, somos capaces de crear CLASES !!!
   
Cuando un ni¤o le dice a su mam , 'quiero ir al circo', el ni¤o no especi-
fica cual ni c¢mo ha de ser, el se refiere a la CLASE CIRCO. Esta usando
lo GENERAL aunque su experiencia siempre ha sido con lo PARTICULAR. ¨Im-
presionante, no?
   
Bien, centr ndome en los bytes... Todos estos factores tan importantes,
pusieron de manifiesto la importancia del OOPS. Hoy, ninguna empresa im-
portante de programaci¢n, duda de la extraordinaria POTENCIA de la
PROGRAMACION ORIENTADA AL OBJETO.
   
Si un ordenador es capaz de simular una sesi¢n de vuelo en avi¢n (un simu-
lador a‚reo), ¨porque no iba a ser capaz de simular el universo de CLASES
y OBJETOS que nos rodea? OOPS...
   
Se ha desarrollado toda una teor¡a del sistema OOPS, cuyas principales
caracter¡sticas paso a describiros:
   
- OBJETO: Es ALGO que tiene una serie de DATOS y que se comporta de una
  formas determinadas ante determinados est¡mulos o mensajes. (Si yo le
  pego un martillazo a un vaso, mi mensaje es 'TE GOLPEO', el vaso saltar 
  en trozos, ese es su METODO para ese MENSAJE ).
   
- CLASE: Mientras que el OBJETO es algo REAL y TANGIBLE, la CLASE es
  ABSTRACTA. La CLASE indica las REGLAS por las que han de crearse y
  comportarse los OBJETOS de esa CLASE. ¨ C¢mo ser¡a la CLASE 'VASO'?
   
     DATOS: Tama¤o, Peso, color, forma...
     METODOS: Llenarse, Rodar, romperse, vaciarse, destruirse, etc...

Existe una regla de ORO que no deb is olvidar: En OOPS todo lo que tenga
una serie de DATOS y REALICE una serie de METODOS es susceptible de ser
CONSTRUIDO COMO CLASE. Esto es muy importante. Cuando se trate de crear
CLASES que tengan similitud con el mundo REAL, ser  muy f cil. Lo dif¡cil
es cuando vayamos a crear CLASES que no tengan nada que ver con el mundo
REAL... Ah¡ la inform tica trasciende a la naturaleza, y nos permitir 
crear CLASES totalmente in‚ditas!
 

[Antonio Linares]

Rafa,

Muchas gracias por tus palabras y por recuperar esos escritos para a quien le pueda servir

Somos una pandilla de locos por el xbase, pero si no fuésemos los que somos (y han sido), no existiría lo que hemos construido entre todos juntos. Y harbour es estandarte de estos "Clipper-hearts", libertad, claridad, sencillez. Le ganamos la partida al lado oscuro que queria sumir a Clipper en el olvido...

Y ahi queda para los que vengan detrás nuestra. Porque aunque sea a muy pequeña escala, hemos hecho historia a nuestra manera y algún dia diran "joder, que zumbados estaban esos tios, pero lo consiguieron" jajajaja

Un Harbour libre for ever!!!

[Carles]

Joe la que he liado...

Estos dias estoy sensible y me vais hacer llorar... Solo queria rescatar un documento que me marco en su dia. Y mi reflexion final es...despues de tanto recorrido desde que lo lei por primera vez, hoy en dia lo sigo aplicando: sap, c, php, android,... Es un santo grial que a uno le ha enseñado a aportar orden y claridad. Pronto Indiana Jones ira a por el, seguro.

Gracias Antonio por liderar a estos locos.


C.

[Antonio Linares]

A por ellos que son pocos y cobardes!!!

Sino fuera por todos, desde el primero hasta el último, lo que hay ahora no existiría, es el fruto de todos nosotros.

Y que más locos que dejarse guiar por otro loco