Hola de nuevo lista...
me parece que si sigo así los voy a pudrir a preguntas... jeje
Dos cosas:
1. Tengo que hacerle un dibujito (una flechita) a un morph, ¿donde empiezo a
revolver para darme una idea de cómo lograrlo?
2. Estoy trabajando en base a un array2D. Muchas de las cosas que estoy haciendo
las termino resolviendo con 3 to: 14 do:... Por lo general me pasa que estoy
tratando de buscar algo en el array, y cuando lo encuentra debería cortar la
búsqueda (porque hay una y sólo una cosa igual (mismo objeto)). La pregunta
sería "¿cómo hago para cortar el #do?", pero me parece que estoy mirando las
cosas muy tradicionalmente. Voy a explicar como viene la cosa para que se
entienda:
Estoy tratando de hacer un juego que consiste en una grilla de 10x10, sobre la
que se van "disparando" fichas de colores. Se pueden disparar de los 4 costados
(ver imagen).
Ahora bien, yo uso de base una grilla de 16x16 donde tengo las fichas. Cuando se
le hace click a alguna de las fichas de los costados, tiene que dispararse la
ficha que está pegada al tablero en la misma linea que la ficha que se le hizo
click. Por ejemplo si le hago click a la ficha que está en (4,1) debería
dispararse la ficha que está en (4,3).
Para hacer esto yo estoy haciendo que la ficha le diga al tablero que fue
clickeada (tablero #clickEnFicha: self) y el tablero tiene que buscar qué ficha
disparar (#fichaEnElBorde: unaFicha), hacia donde (#direccion: unaFicha) y hasta
donde. Las dos primeras acciones dependen del costado en el cual se haga click,
y la última de las fichas que ya están en el tablero.
Lo que estoy haciendo por ahora para #fichaEnElBorde y #direccion es buscar
unaFicha entre todos los costados, lo cual me implica cuatro "n to: m do:". Para
saber "hasta donde", tengo que fijarme donde está la primer ficha contra la cual
impactaría la que se va a disparar.
Para ambos casos es necesario cortar el #do:, pero me parece que debo estar
planteando mal las cosas.
Bue... me quedó un mail larguísimo... sabré entender si les da fiaca
responderme.
Sergio Del Franco (Cyberangel, Sergiodf)
Capital Federal - Argentina
sergiodf@...
http://sergiodf.com.ar
ICQ#21632250
... Busco abogado para juicio final.
--
-------------------------------------------------
Saturemos Echelon:
you must put this bomb tomorrow to begin this new
act of war against the United States of America
-------------------------------------------------
Sergio:
Mirá el código del Same, ahí verás algo de la seleccion fila columna que me
parece que usar,
Si es solo un objeto que responde al mensaje Objeto = condicion , podés
usar
Resultado _ ColeccionOriginal select: [:cual | cual = concicion ] colect:
[:miObjeto | miObjeto ].
Tal vez alguien con mas experiencia te de un mejor consejo.
En cuanto a la flechita , yo uso mucho para los dibujos archivos .gif o .jpg
externos y creo los morphs a partir de los dibujos.
Te mando un códoio para obtener botones (IconicButton) a partir de un
directorio.
Extrae lo que te sirva y sino manda mas mail
| slash oldFolder newFolder listaArchivos archivo pos aFileName f
esteBoton fileStream selector cadena |
slash _ FileDirectory slash.
"Toma el separador de directorios, no es el mismo en todos los OS"
oldFolder _ FileDirectory default.
"Guarda el directorio de arranque"
newFolder _ FileList2 modalFolderSelector.
"Invoca la ventana de dialogo para seleccionar directorio"
listaArchivos _ newFolder fileNamesMatching: '*.jpg'.
"Solo nos interesan los .jpg para este ejercicio"
newFolder _ newFolder pathName , slash.
FileDirectory setDefaultDirectory: newFolder.
"Seteamos al directorio elegido"
1
to: listaArchivos size
do: [:i |
"Recorremos la lista de archivos que concuerdan con el criterio
elegido"
archivo _ listaArchivos at: i.
pos _ archivo findString: '.'.
aFileName _ (archivo copyFrom: 1 to: pos)
, 'morph'.
"Creamos un nuevo nombre de archivo"
cadena _ '#'
, (archivo copyFrom: 1 to: pos).
selector _ Symbol readFromString: cadena.
"Creamos un simbolo a partir del nombre de archivo"
f _ Form fromFileNamed: archivo.
"Leemos el archivo dentro de un Form"
f _ f magnifyBy: 0.5.
esteBoton _ IconicButton new.
"Creamos una instancia de IconicButton"
esteBoton initialize.
"La inicializamos"
esteBoton labelGraphic: f.
"Hacemos que utilice nuestro grafico"
esteBoton extent: f asMorph extent.
"Ajustamos el tamaño al tamalo del dibujo"
esteBoton target: self.
"Por defecto los mensajes serár enviados a la clase Utilitarios"
esteBoton actionSelector: selector.
"Y la acciona a ejecutar es el nombre del boton"
esteBoton openInWorld.
fileStream _ FileStream newFileNamed: aFileName.
"Abrimos un archivo de salida y grabamos"
fileStream fileOutClass: nil andObject: esteBoton].
FileDirectory setDefaultDirectory: oldFolder pathName
"Al teminar volvemos al directorio default"
Edgar
Ahora podés usar Yahoo! Messenger desde tu celular. Aprendé cómo hacerlo en
Yahoo! Móvil: http://ar.mobile.yahoo.com/sms.html
Hola Sergio,
> 1. Tengo que hacerle un dibujito (una flechita) a un
> morph, ¿donde empiezo a revolver para darme
> una idea de cómo lograrlo?
Si la flechita es simple y no cambia de tamaño ni aspecto podes usar una
imagen (Form) y dibujarla con transparencia.
Si la flecha es variable y refiere a dos objetos que pueden moverse (y la
flecha debe moverse sola...) te recomiendo ver el trabajo de Ned Konz
(NK-Connectors).
Seguramente podes encontrar el proyecto en el swiki.
También podes ver una buena forma de uso en GIM
(http://www.smalltalking.net/GIM.zip)
> 2. Estoy trabajando en base a un array2D. Muchas de las cosas que estoy
haciendo las termino resolviendo con 3 to: 14 do:... Por lo general me pasa
que estoy tratando de buscar algo en el array, y cuando lo encuentra debería
cortar la búsqueda (porque hay una y sólo una cosa igual (mismo objeto)). La
pregunta sería "¿cómo hago para cortar el #do?", pero me parece que estoy
mirando las cosas muy tradicionalmente.
Fijate en los mensajes de Collection
#detect:
#detect:ifNone:
#select:
#reject:
#collect:
#inject:into
Son todos muy útiles.
Fijate en estas expresiones de ejemplo:
'mi mama me mima' detect: [:one| one isVowel ]
'mi mama me mima' select: [:one| one isVowel ]
'mi mama me mima' reject: [:one| one isVowel ]
#(1 2 3 4 5) collect: [:each| each factorial ]
Object subclasses collect: [:each| each subclasses ]
Object subclasses select: [:each| each subclasses isEmpty ]
Suerte!
hasta pronto,
Ale.
----- Original Message -----
From: "Sergio Del Franco" <sergiodf@...>
To: "Lista Smalltalking" <smalltalking@...>
Sent: Sunday, September 01, 2002 5:39 AM
Subject: [objetos] Req: consultas varias Squeak
> Hola de nuevo lista...
> me parece que si sigo así los voy a pudrir a preguntas... jeje
>
> Dos cosas:
> 1. Tengo que hacerle un dibujito (una flechita) a un morph, ¿donde empiezo
a revolver para darme una idea de cómo lograrlo?
>
> 2. Estoy trabajando en base a un array2D. Muchas de las cosas que estoy
haciendo las termino resolviendo con 3 to: 14 do:... Por lo general me pasa
que estoy tratando de buscar algo en el array, y cuando lo encuentra debería
cortar la búsqueda (porque hay una y sólo una cosa igual (mismo objeto)). La
pregunta sería "¿cómo hago para cortar el #do?", pero me parece que estoy
mirando las cosas muy tradicionalmente. Voy a explicar como viene la cosa
para que se entienda:
>
> Estoy tratando de hacer un juego que consiste en una grilla de 10x10,
sobre la que se van "disparando" fichas de colores. Se pueden disparar de
los 4 costados (ver imagen).
> Ahora bien, yo uso de base una grilla de 16x16 donde tengo las fichas.
Cuando se le hace click a alguna de las fichas de los costados, tiene que
dispararse la ficha que está pegada al tablero en la misma linea que la
ficha que se le hizo click. Por ejemplo si le hago click a la ficha que está
en (4,1) debería dispararse la ficha que está en (4,3).
> Para hacer esto yo estoy haciendo que la ficha le diga al tablero que fue
clickeada (tablero #clickEnFicha: self) y el tablero tiene que buscar qué
ficha disparar (#fichaEnElBorde: unaFicha), hacia donde (#direccion:
unaFicha) y hasta donde. Las dos primeras acciones dependen del costado en
el cual se haga click, y la última de las fichas que ya están en el tablero.
> Lo que estoy haciendo por ahora para #fichaEnElBorde y #direccion es
buscar unaFicha entre todos los costados, lo cual me implica cuatro "n to: m
do:". Para saber "hasta donde", tengo que fijarme donde está la primer ficha
contra la cual impactaría la que se va a disparar.
> Para ambos casos es necesario cortar el #do:, pero me parece que debo
estar planteando mal las cosas.
>
>
> Bue... me quedó un mail larguísimo... sabré entender si les da fiaca
responderme.
>
>
> Sergio Del Franco (Cyberangel, Sergiodf)
> Capital Federal - Argentina
> sergiodf@...
> http://sergiodf.com.ar
> ICQ#21632250
>
> ... Busco abogado para juicio final.
> --
> -------------------------------------------------
> Saturemos Echelon:
> you must put this bomb tomorrow to begin this new
> act of war against the United States of America
> -------------------------------------------------
> Para retirarse del grupo,
> puede enviar un email a:
> smalltalking-unsubscribe@egroups.com
>
>
> Tu uso de Yahoo! Grupos está sujeto a las
http://ar.docs.yahoo.com/info/utos.html
>
>
----------------------------------------------------------------------------
----
Hola gente: Necesito hacer algunas consultas puntuales. En principio
quisiera un apoyo teórico con respecto a la clase OrderedCollection:
¿Podrían decirme con pocas palabras para que se usan estos métodos?
#reject:
#detect:ifNone:
#do:
No logro entender bien la sintáxis de estos métodos ¿A qué le llama
<MonadicValuable>?
Otra pregunta: ¿cual es la mejor forma de aprender a usar el depurador? Me
encantaría entenderlo. Algunas cosas las entiendo pero otras no hay forma, y
me sería muy útil.
Desde ya muchas gracias.
Hola Pablo,
>Hola gente: Necesito hacer algunas consultas puntuales. En principio
>quisiera un apoyo teórico con respecto a la clase OrderedCollection:
>¿Podrían decirme con pocas palabras para que se usan estos métodos?
> #reject:
El #reject: se lo envias a unaCollection y le pasas un bloque como
parámetro, lo que hace es devolverte una colección con los elementos que
no cumplan la condición dentro del bloque, por ejemplo:
coleccion:= OrderedCollection new
coleccion add: nil.
coleccion add: 4.
coleccion add: 'unString'.
coleccion add: true.
coleccion reject:[:each | each isNil]
el último mensaje te va a devolver una colección con los siguientes
objetos:
4
'unString'
true
El select: hace exactamente lo contrario.
> #detect:ifNone:
El detect:ifNone lo recibe también una colección y lo que hace es
devolverte el primero objeto de esa colección que cumpla con la
condición que le pusiste en el primer bloque, el segundo bloque (después
del ifNone:) lo va a evaluar en el caso de que no encuentre ningún
objeto que cumpla con esa condición. O sea, en el ifNone: ponés lo que
querés que haga si no hay ningún objeto como el que buscás.
Por ej:
coleccion detect:[:each | each = 4] ifNone:[^false]
Si el 4 sigue en la coleccion entonces te lo va a devolver. De lo
contrario te va a devolver el objeto false.
> #do:
Finalmente el do:
Lo que hace es ejecutar el bloque una vez por cada elemento de la
colección
Y te devuelve el receptor.
Por ejemplo:
coleccion do:[:each | each printOn: Transcript ]
Te va a mostrar lo siguiente en el Transcript:
nil
4
'unString'
true
>No logro entender bien la sintáxis de estos métodos ¿A qué le llama
><MonadicValuable>?
La verdad es que yo no sé lo que es... ¿alguien puede explicarlo?
>Otra pregunta: ¿cual es la mejor forma de aprender a usar el depurador?
Me
>encantaría entenderlo. Algunas cosas las entiendo pero otras no hay
forma, >y me sería muy útil.
A mí criterio, la mejor forma de aprender a usar el depurador es
equivocándote y teniendo que utilizarlo.. metiendo los dedos digamos.
>Desde ya muchas gracias.
Saludos
Osvaldo
FYI
----- Mensaje original -----
De: M.Alejandra de Bonis
Enviado: Lunes 2 de Septiembre de 2002 12:16
Asunto: [poo-uba] Fw: Búsqueda Programadores Smalltalk
Hola a todos.
Trabajo en una empresa de software orientada al dominio financiero en la
cual se programa en Smalltalk.
Quieren incorporar a nuevos programadores.
Los interesados por favor enviar Curriculum Vitae a esta dirección.
Desde ya muchas gracias.
M.Alejandra De Bonis
a.debonis@...
Hola:
>No logro entender bien la sintáxis de estos métodos ¿A qué le llama
><MonadicValuable>?
No te preocupes por eso (el MonadicValuable), si no me equivoco le agregan
esa palabreja porque asi es como esta especificado en el ANSI Smalltalk.
Por favor, no preguntes que significa exactamente porque no lo lei aun.
Saludos
GallegO
este mail es para informar el cambio de direccion electronica a partir de la fecha, por favor actualice sus bases de datos y/o libreta de direcciones
la vieja direccion electronica l2n@... es reemplazada por :
para envios personales l2n-@... ( observar el guion medio entre la ene y la arroba tuve que ponerlo ya que el usuario en este proveedor tiene que tener no menos de 4 digitos)
Hola a Todos , cortita
monadic valuable: An object which implements the
ANSI <monadicValuable> protocol, for example a one
argument block. Monadic valuables are evaluated by
sending them the #value: message with one argument.
Saludos a Todos
Marcelo Diaz Cortez ( MDC)
--- GallegO <fxgallego@...> escribió: >
Hola:
>
> >No logro entender bien la sintáxis de estos métodos
> ¿A qué le llama
> ><MonadicValuable>?
>
> No te preocupes por eso (el MonadicValuable), si no
> me equivoco le agregan
> esa palabreja porque asi es como esta especificado
> en el ANSI Smalltalk.
>
> Por favor, no preguntes que significa exactamente
> porque no lo lei aun.
>
> Saludos
> GallegO
>
>
>
Ahora podés usar Yahoo! Messenger desde tu celular. Aprendé cómo hacerlo en
Yahoo! Móvil: http://ar.mobile.yahoo.com/sms.html
Gracias GallegO! Es el defecto que por ahí tengo; soy demasiado teórico. La
estoy peleando, hasta ahora vamos empate ja.
Saludos.-
----- Original Message -----
From: GallegO
To: smalltalking@...
Sent: Monday, September 02, 2002 5:59 PM
Subject: Re: [objetos] Dolphin 4.0. // nuevas consultas.
Hola:
>No logro entender bien la sintáxis de estos métodos ¿A qué le llama
><MonadicValuable>?
No te preocupes por eso (el MonadicValuable), si no me equivoco le agregan
esa palabreja porque asi es como esta especificado en el ANSI Smalltalk.
Por favor, no preguntes que significa exactamente porque no lo lei aun.
Saludos
GallegO
Para retirarse del grupo,
puede enviar un email a:
smalltalking-unsubscribe@egroups.com
Tu uso de Yahoo! Grupos está sujeto a las Condiciones del servicio de
Yahoo!.
Muchísimas gracias Osvaldo. Muy útil tu respuesta.
Saludos.-
----- Original Message -----
From: Osvaldo Aufiero
To: smalltalking@...
Sent: Monday, September 02, 2002 3:17 PM
Subject: RE: [objetos] Dolphin 4.0. // nuevas consultas.
Hola Pablo,
>Hola gente: Necesito hacer algunas consultas puntuales. En principio
>quisiera un apoyo teórico con respecto a la clase OrderedCollection:
>¿Podrían decirme con pocas palabras para que se usan estos métodos?
> #reject:
El #reject: se lo envias a unaCollection y le pasas un bloque como
parámetro, lo que hace es devolverte una colección con los elementos que
no cumplan la condición dentro del bloque, por ejemplo:
coleccion:= OrderedCollection new
coleccion add: nil.
coleccion add: 4.
coleccion add: 'unString'.
coleccion add: true.
coleccion reject:[:each | each isNil]
el último mensaje te va a devolver una colección con los siguientes
objetos:
4
'unString'
true
El select: hace exactamente lo contrario.
> #detect:ifNone:
El detect:ifNone lo recibe también una colección y lo que hace es
devolverte el primero objeto de esa colección que cumpla con la
condición que le pusiste en el primer bloque, el segundo bloque (después
del ifNone:) lo va a evaluar en el caso de que no encuentre ningún
objeto que cumpla con esa condición. O sea, en el ifNone: ponés lo que
querés que haga si no hay ningún objeto como el que buscás.
Por ej:
coleccion detect:[:each | each = 4] ifNone:[^false]
Si el 4 sigue en la coleccion entonces te lo va a devolver. De lo
contrario te va a devolver el objeto false.
> #do:
Finalmente el do:
Lo que hace es ejecutar el bloque una vez por cada elemento de la
colección
Y te devuelve el receptor.
Por ejemplo:
coleccion do:[:each | each printOn: Transcript ]
Te va a mostrar lo siguiente en el Transcript:
nil
4
'unString'
true
>No logro entender bien la sintáxis de estos métodos ¿A qué le llama
><MonadicValuable>?
La verdad es que yo no sé lo que es... ¿alguien puede explicarlo?
>Otra pregunta: ¿cual es la mejor forma de aprender a usar el depurador?
Me
>encantaría entenderlo. Algunas cosas las entiendo pero otras no hay
forma, >y me sería muy útil.
A mí criterio, la mejor forma de aprender a usar el depurador es
equivocándote y teniendo que utilizarlo.. metiendo los dedos digamos.
>Desde ya muchas gracias.
Saludos
Osvaldo
Para retirarse del grupo,
puede enviar un email a:
smalltalking-unsubscribe@egroups.com
Tu uso de Yahoo! Grupos está sujeto a las Condiciones del servicio de
Yahoo!.
Hola Pablo,
> Hola gente: Necesito hacer algunas consultas puntuales. En principio
> quisiera un apoyo teórico con respecto a la clase OrderedCollection:
Aprovecho para hacer algunas acotaciones más, espero no
te molesten, es para ir ajustando algunas ideas...
> ¿Podrían decirme con pocas palabras para que se usan estos métodos?
> #reject:
> #detect:ifNone:
> #do:
Estos no son métodos, sino nombres de mensajes.
En lo nuestro son muy importantes los mensajes y los métodos solo tienen
valor anegdótico, para un objeto de una clase determinada.
Un mensaje (que es un objeto) tiene mucho mas valor pues puede ser utilizado
para objetos de cualquier clase.
La recepcion de un mensaje por un objeto, implica el cierre de "un contrato"
entre el objeto que emitió el mensaje y el que lo recibe.
Este contrato tiene un sentido (semántico) que es acordado implisitamente
entre emisor y receptor del mensaje y está indicado de manera breve en el
nombre del mensaje.
Al nombre de un mensaje se lo acostumbra a llamar "selector" y normalmente
es un objeto de clase Symbol (que es como un String pero que es único en el
ambiente).
Bueno, a tu pregunta...
Entendiste que hace el #select: ?
El #select: es un mensaje que tiene el objetivo de seleccionar en elementos
en el receptor del mensaje aquellos que cumplen con una condición.
La "condición" es un objeto (no podría ser de otra manera ;) que expresa un
comportamiento (a estos objetos "comportamiento" los llamamos bloques)
identico al caso de los mensajes #ifTrue: , #ifFalse:, #and: , etc...
Para entender los bloques tenes que leerlos como si fuera una condicion
matemática; por ejm.
Clientes select: [:each| each esDeudor ]
Seleccion de los clientes tal que son deudores.
Fijate por ejemplo otros casos como:
'ajhsdauyiheiuahdu' select: [:each| each isVowel ]
El select tiene como argumento un bloque que se evaluará para determinar si
un elemento es selecto. Por eso, el bloque debe tener un (y solo un)
argumento.
La evaluación de un bloque con un argumento se realiza enviandole el mensaje
#value:
y esto determina que lo que pasas como argumento en un #select: pueda ser
unb bloque O CUALQUIER otro objeto que entienda #value: !
Es decir, que podes utilizar cualquier objeto de cualquier clase para hacer
un #select: es decir, podes modelar tus propios criterios... acciones, etc.
Solo es necesario que el objeto entienda el mansaje #value: pues se enviará
este mensaje para hacer el #select:
> #reject:
El reject es similar al select pero te devuelve los objetos que contestaron
"false" a argumento de seleccion.
> #detect:ifNone:
El detect detecta un objeto que cumpla con la condicion y lo devuelve, sin
seguir buscando...
> #do:
Aplica el bloque que le pasas como argumento a todos los elementos del
receptor.
Tené en cuenta que "el receptor" puede ser tanto una coleccion como
CUALQUIER objeto que entienda el mensaje #do:
Que quiero resaltar con esto?
Que el mensaje #do: no ES de Collection...
Es un mensaje que entienden las colecciones... pero cualquier objeto puede
implementarlo, respetando su semántica.
En resumen, los mensajes NO pertenecena clases,
son independientes de la clasificación.
> No logro entender bien la sintáxis de estos métodos
> ¿A qué le llama <MonadicValuable>?
"Monadic" es que tiene un argumento.
"Valuable" que es evaluable ( #value: ).
Ambos términos se definen en el ANSI Smalltalk (podes ver el documento X3J20
dodne esto se aclara, como muchos otros términos tórpes apra definir
interfaces de los objetos de base de Smnalltalk).
> Otra pregunta: ¿cual es la mejor forma de aprender a usar el depurador? Me
> encantaría entenderlo. Algunas cosas las entiendo pero otras no hay forma,
y
> me sería muy útil.
Lamentablemente la mejor forma es usándolo o mejor aún, viendo a otro que lo
hace.
Idem para el Inspector y el Browser.
Quizás te parezcan mas "normales/simples" el inspector y el browser; es
decir, pronto se aprende como funcionan.
Pero cuidado, normalmente se tarda mucho tiempo para aprender a usarlos.
No son herramientas tan inocentes como se ven. ;-)
A modo de ejemplo breve, es común ver que la gente usa el browser para
"codificar" y escriben un sistema usando Smalltalk como lo hacían en otros
lenguajes (OO).
Solo después de tener la oportunidad de trabajar en grupo con gente que
tiene experiencia se aprende a hacer mas escribiendo menos...
Construir un sistema de objetos, es crear objetos, no escribir código.
(al decir crear objetos, estamos diciendo objetos...
que no sean de la clase CompiledMethod ;-)
hasta pronto,
Ale.
Hola Ale, podrías explicar un poco más esto por favor?
> Construir un sistema de objetos, es crear objetos, no escribir código.
(al decir crear objetos, estamos diciendo objetos...
que no sean de la clase CompiledMethod ;-)
Gracias
Osvaldo
Muchísimas gracias Ale...! Estas acotaciones nunca molestan; al contrario;
enriquecen y me dan un marco conceptual que en mi caso lo necesito para
aprender, más aún en mi caso (para bien o para mal tengo una tendencia a
entender las cosas de un modo teórico) y de paso a usar bien los términos
(sino les iba a seguir diciendo métodos cuando son mensajes aplicables a
varias clases). Ya que aún no puedo dar respuestas espero que mis preguntas
enriquezcan al grupo. Saludos a todos.
----- Original Message -----
From: Alejandro F. Reimondo
To: smalltalking@...
Sent: Monday, September 02, 2002 7:26 PM
Subject: Re: [objetos] Dolphin 4.0. // nuevas consultas.
Hola Pablo,
> Hola gente: Necesito hacer algunas consultas puntuales. En principio
> quisiera un apoyo teórico con respecto a la clase OrderedCollection:
Aprovecho para hacer algunas acotaciones más, espero no
te molesten, es para ir ajustando algunas ideas...
> ¿Podrían decirme con pocas palabras para que se usan estos métodos?
> #reject:
> #detect:ifNone:
> #do:
Estos no son métodos, sino nombres de mensajes.
En lo nuestro son muy importantes los mensajes y los métodos solo tienen
valor anegdótico, para un objeto de una clase determinada.
Un mensaje (que es un objeto) tiene mucho mas valor pues puede ser utilizado
para objetos de cualquier clase.
La recepcion de un mensaje por un objeto, implica el cierre de "un contrato"
entre el objeto que emitió el mensaje y el que lo recibe.
Este contrato tiene un sentido (semántico) que es acordado implisitamente
entre emisor y receptor del mensaje y está indicado de manera breve en el
nombre del mensaje.
Al nombre de un mensaje se lo acostumbra a llamar "selector" y normalmente
es un objeto de clase Symbol (que es como un String pero que es único en el
ambiente).
Bueno, a tu pregunta...
Entendiste que hace el #select: ?
El #select: es un mensaje que tiene el objetivo de seleccionar en elementos
en el receptor del mensaje aquellos que cumplen con una condición.
La "condición" es un objeto (no podría ser de otra manera ;) que expresa un
comportamiento (a estos objetos "comportamiento" los llamamos bloques)
identico al caso de los mensajes #ifTrue: , #ifFalse:, #and: , etc...
Para entender los bloques tenes que leerlos como si fuera una condicion
matemática; por ejm.
Clientes select: [:each| each esDeudor ]
Seleccion de los clientes tal que son deudores.
Fijate por ejemplo otros casos como:
'ajhsdauyiheiuahdu' select: [:each| each isVowel ]
El select tiene como argumento un bloque que se evaluará para determinar si
un elemento es selecto. Por eso, el bloque debe tener un (y solo un)
argumento.
La evaluación de un bloque con un argumento se realiza enviandole el mensaje
#value:
y esto determina que lo que pasas como argumento en un #select: pueda ser
unb bloque O CUALQUIER otro objeto que entienda #value: !
Es decir, que podes utilizar cualquier objeto de cualquier clase para hacer
un #select: es decir, podes modelar tus propios criterios... acciones, etc.
Solo es necesario que el objeto entienda el mansaje #value: pues se enviará
este mensaje para hacer el #select:
> #reject:
El reject es similar al select pero te devuelve los objetos que contestaron
"false" a argumento de seleccion.
> #detect:ifNone:
El detect detecta un objeto que cumpla con la condicion y lo devuelve, sin
seguir buscando...
> #do:
Aplica el bloque que le pasas como argumento a todos los elementos del
receptor.
Tené en cuenta que "el receptor" puede ser tanto una coleccion como
CUALQUIER objeto que entienda el mensaje #do:
Que quiero resaltar con esto?
Que el mensaje #do: no ES de Collection...
Es un mensaje que entienden las colecciones... pero cualquier objeto puede
implementarlo, respetando su semántica.
En resumen, los mensajes NO pertenecena clases,
son independientes de la clasificación.
> No logro entender bien la sintáxis de estos métodos
> ¿A qué le llama <MonadicValuable>?
"Monadic" es que tiene un argumento.
"Valuable" que es evaluable ( #value: ).
Ambos términos se definen en el ANSI Smalltalk (podes ver el documento X3J20
dodne esto se aclara, como muchos otros términos tórpes apra definir
interfaces de los objetos de base de Smnalltalk).
> Otra pregunta: ¿cual es la mejor forma de aprender a usar el depurador? Me
> encantaría entenderlo. Algunas cosas las entiendo pero otras no hay forma,
y
> me sería muy útil.
Lamentablemente la mejor forma es usándolo o mejor aún, viendo a otro que lo
hace.
Idem para el Inspector y el Browser.
Quizás te parezcan mas "normales/simples" el inspector y el browser; es
decir, pronto se aprende como funcionan.
Pero cuidado, normalmente se tarda mucho tiempo para aprender a usarlos.
No son herramientas tan inocentes como se ven. ;-)
A modo de ejemplo breve, es común ver que la gente usa el browser para
"codificar" y escriben un sistema usando Smalltalk como lo hacían en otros
lenguajes (OO).
Solo después de tener la oportunidad de trabajar en grupo con gente que
tiene experiencia se aprende a hacer mas escribiendo menos...
Construir un sistema de objetos, es crear objetos, no escribir código.
(al decir crear objetos, estamos diciendo objetos...
que no sean de la clase CompiledMethod ;-)
hasta pronto,
Ale.
Para retirarse del grupo,
puede enviar un email a:
smalltalking-unsubscribe@egroups.com
Tu uso de Yahoo! Grupos está sujeto a las Condiciones del servicio de
Yahoo!.
Niladic Valuable - que no tiene argumentos
Monadic Valuable - que tiene un argumento
Dyadic Valuable - que tiene dos argumentos.
Mira los metodos #value, #value:, #value:value: en la clase BlockClosure.
Saludos Bruno.
Muchas gracias. Bruno!
----- Original Message -----
From: Bruno Buzzi Brasesco
To: smalltalking@...
Sent: Tuesday, September 03, 2002 8:55 AM
Subject: Re: [objetos] Dolphin 4.0. // nuevas consultas.
Niladic Valuable - que no tiene argumentos
Monadic Valuable - que tiene un argumento
Dyadic Valuable - que tiene dos argumentos.
Mira los metodos #value, #value:, #value:value: en la clase BlockClosure.
Saludos Bruno.
Para retirarse del grupo,
puede enviar un email a:
smalltalking-unsubscribe@egroups.com
Tu uso de Yahoo! Grupos está sujeto a las Condiciones del servicio de
Yahoo!.
Holass,
--- En smalltalking@g..., "Osvaldo Aufiero" <osvaldoa@4...> escribió:
> Hola Ale, podrías explicar un poco más esto por favor?
>
> > Construir un sistema de objetos, es crear objetos, no escribir
código.
> (al decir crear objetos, estamos diciendo objetos...
> que no sean de la clase CompiledMethod ;-)
Yo no soy Ale, pero si queres te explico un poquito ;-)
Lo que quiere decir Ale con esto es que al trabajar en un "Ambiente
de Objetos" con un grupo de desarrollo en el cual haya al menos una
persona experimentada en el manejo de Grupos para trabajar "Con
Objetos" se hace completamente diferente a la típica manera de
trabajar que conocemos la mayoría, en la cual el lider del proyecto
viene y dice: 'hay que hacer tal cosa' y después tenés a 10 tipos
matandose "codificando" para que esa tal cosa salga.
Con objetos es diferente, de esta manera se suele trabajar haciendo
reuniones de "smalltalking" (no las de este grupo eh! ;-), que
consisten en juntarse y pensar cual sería la mejor manera de
construir tal cosa con objetos, estas reuniones pueden tener una
vision acotada a un tema, o mas globales, si es que el proyecto está
en pañales, una ves definido un bosquejo de lo que se piensa hacer,
por lo general se juntan en personas de a dos para distintos temas,
dependiendo de su complejidad, y para cada tema global se va
construyendo un framework de base.
Por ejemplo, si tu aplicacion incluye persisitencia, habria que
construir un framework con Objetos para que se encarguen de resolver
este problema, y aca está la diferencia entre construir un Framework
con objetos vs. codificar/programar. Si codificas en una parte del
sistema para persistir tus objetos, sin construir objetos que se
encarguen de ello, es muy probable que luego, en otra parte del
sistema, necesiten hacer lo mismo, repetir ese codigo para que
funcione en otro lado.
Al construir Frameworks, te quedan objetos reutilizables para
cualquier parte del sistema e incluso, con alguna adaptación, para
otros sistemas. A esto se refería Ale con Hacer mas, escribiendo
menos!!!
Lamentablemente, son muy pocos los lugares en los que se trabaja de
esta manera, por lo que despues hay que atenerse a las consecuencias
de lidiar con un sistema emparchado por todos lados, y lleno de
código repetido. A esta forma de trabajar yo la comparo con la tarea
de alimentar a un Elefante, al cual le vas dando de comer, y engorda
cada vez mas, hasta que llega un momento que es tan pesado que se
hace inmanejable.
Bueno, aunque no con la filosofía de Ale, traté de explicarte muy por
arriba a que se refiería Ale con eso.
HAAA! y con esto:
> (al decir crear objetos, estamos diciendo objetos...
> que no sean de la clase CompiledMethod ;-)
Esta queriendo decir que construyamos objetos que no sean metodos, ya
que tus metodos, tambien son objetos, pertenecen a la clase
CompiledMethod ;-)
Salu2, ElGuiyE
Soy nuevo en el mundo de las OODB, no tengo mucho conocimiento en el manejo de la herramienta que descargué para el manejo de base de datos orientadas a objetos. Agradecería si pueden colaborarme indicandome la manera de trabajar en esta herramienta.
De antemano agradezco su colaboración.
Únase al mayor servicio mundial de correo electrónico: Haga clic aquí
Hola sos de la UTN Rosario.
Si es asi en rosario hay un pequenio grupo de gente que le interesa
Squeak.
Saludos
Mario.
On Thu, 29 Aug 2002, Sergio Del Franco wrote:
> Hola lista,
>
> Les comento que para la materia Habilitación Profesional de la UTN (para el
título intermedio) me propuse como proyecto hacer un juego en Squeak
>
> Ahora que me empecé a meter con código, me saltan algunas pequeñas dudas.
> La mayoría las voy salvando gracias a internet y las herramientas propias del
Squeak, pero ahora tengo una que es conceptual. Veamos:
>
> El juego tiene un nivel de dificultad entre 5 y 10 (la cantidad de colores)
> Para hacer juegoNuevo: aNumber, tengo que validar que aNumber sea entre 5 y
10.
> Yo lo hice de una forma pero me resulta asquerosamente "tradicional", así que
pido la ayuda a los que llevan un tiempo para que me guíen por el buen camino
>
>
> juegoNuevo: aNumber
> "crea un juego nuevo con dificultad <aNumber>"
>
> |dificultad|
> aNumber > 10 ifTrue: [dificultad _ 10].
> aNumber < 5 ifTrue: [dificultad _ 5].
> dificultad isNil: [dificultad _ aNumber].
> colores _ Color wheel: dificultad.
> "y acá seguiría..."
>
> Gracias desde el vamos...
>
>
> Sergio Del Franco (Cyberangel, Sergiodf)
> Capital Federal - Argentina
> sergiodf@...
> http://sergiodf.com.ar
> ICQ#21632250
>
> ... Ladrones abstenerse. El estado no admite competencia.
> --
> -------------------------------------------------
> Saturemos Echelon:
> you must put this bomb tomorrow to begin this new
> act of war against the United States of America
> -------------------------------------------------
>
> Para retirarse del grupo,
> puede enviar un email a:
> smalltalking-unsubscribe@egroups.com
>
>
> Tu uso de Yahoo! Grupos está sujeto a las
http://ar.docs.yahoo.com/info/utos.html
>
>
>
hay un grupo en la utn y me parece que en la uai tambien, no se si es el
mismo u otro... consulta con el Lic. Edgar J. De Cleene cuya direccion
electronica es esta edgardec2001@...
y es profesor de la uai
SERGIO ALEJANDRO SILICANI
DUEÑO GERENTE
LOS 2 NEGRITOS
l2n-@...
los2negritos@...
ICQ N°12865881
SAN NICOLAS PROV BS AS
ARGENTINA
Sergio:
Gracias por la propaganda.
Es el mismo tristemente célebre SqueakRos, cuya página es
http://edgardec.fwd.com.ar/.
Aquí se va subiendo de vez en cuando ejemplos, tutoriales , etc.
Tengo hechos un puzzle , un teg y ahora estoy con los chicos de este año
armando un planificador de trenes eléctricos.
El mejor punto de partida es el mismo Squeak, yo recomiendo bajarse
urgentemente la última versión estable Squeak3.2-4956 y desde adentro del
Squeak entrar al BovSuperSwiki y cargar el proyecto Learning with Morphic
(el último que haya que creo es 015).
Pero ya vi que Ned Konz in person le contestó como renombrar directorios.
Así que el que sepa inglés que importune a la lista internacional.
Ned es uno de los recapos, autor de los conectors.
Insistan que esta gente si sabe y da buenas ayudas.
Con lo que mandaron de los Changes Sets, lo vamos a traducir y hacer uno
solo con el que teníamos.
Suerte y aguante el Squeak.
Edgar
Ahora podés usar Yahoo! Messenger desde tu celular. Aprendé cómo hacerlo en
Yahoo! Móvil: http://ar.mobile.yahoo.com/sms.html
Hola Gente, yo de nuevo. Una consulta: ¿alguien me sabría decir si hay algún
sitio como para sacar información sobre tecnología de objetos aplicada a la
música? Si alguien sabe algo tirenme alguna dirección. Este es en realidad
un objetivo lejano (armar algo relacionado con música - composición) pero
puede venir bien empezar a leer algo.
Muchas gracias.-
Gemstone es una Base de Objetos, es decir, cada servidor define espacios donde podes alojar objetos.
NO es una OODB, pues no es "orientada" a objetos, ni un esquema de persistencia de objetos, sino una base de objetos, es decir, un espacio de objetos activos (los objetos funcionan "en el disco").
El modelo es simple; cada espacio aloja objetos (es decir, el contenido de un objeto y su comportamiento, es decir, NO solo su estructura o sus datos, sino también su comportamiento).
Si necesitas guardar mas objetos, agregas mas espacio (en los servidores se denomina "extent" a estos espacios).
Un extent puede alojar muchos objetos y de cualquier clase; aunque también hay potilicas para su optimización...
De esta forma, la base de objetos es un espacio colaborativo de objetos que funcionan de manera distribuida.
Como cada objeto "incluye/lleva" su comportamiento no importa donde esté y es totalmente transparente el funcionamiento del sistema en forma local o distribuida (es solo un tema de configuración donde tenes tus objetos y como los alojas, etc.).
De esta manera, como es de esperar estos espacios son un smalltalk, es decir, cada espacio puede tener procesos/procesadores que "hacen vivir" a los objetos que alojan.
Un espacio se comunica con otro por un esquema de distribución transparente, lo que te permite usar las herramientas tradicionales (Browser e inspectores remotos) sobre los objetos que están viviendo en cualquier espacio (en el disco).
Bueno, esta es la base de como entender una Base de Objetos.
Hay muchas alternativas para guardar objetos en un contexto pasivo y toda una gama de soluciones para el tema de "Persistencia". No es apropiado usar la misma solución para todos los casos.
Por último, no dejes de leer los manuales de Gemstone, allí tenes mucho material de valor.
Soy nuevo en el mundo de las OODB, no tengo mucho conocimiento en el manejo de la herramienta que descargué para el manejo de base de datos orientadas a objetos. Agradecería si pueden colaborarme indicandome la manera de trabajar en esta herramienta.
De antemano agradezco su colaboración.
Únase al mayor servicio mundial de correo electrónico: Haga clic aquí
Para retirarse del grupo, puede enviar un email a: smalltalking-unsubscribe@egroups.com
Hola Osvaldo,
Aprender a trabajar con Objetos no es fácil (aprender a trabajar solo
Orientado a Objetos es muy fácil, hay muchos manuales metodologías
propuestas, etc. ;).
Lo mas sorprendente es que uno siempre piensa por un lado que "aprendió
todo" y por otro que puede mejorar solo "un poquito mas".
Esto hace que el camino del aprendizaje sea muy entusiasmante, pero también
hace que uno pueda no darse cuenta cuando deja de avanzar en el
aprendizaje... y equivocadamente pensar que es la mejor manera en la que
puede trabajar la que actualmente conoce (esto no solo pasa a personas sino
a empresas y organizaciones que invierten poco en la capacitación
tecnológica).
A continuación voy a comentar algunos "escalones" que tiene el aprendizaje
del trabajo con Objetos.
La superación de esos escalones es un desafío personal y está condicionado a
las oportunidades de realización dadas por el contexto social (quienes sean
tus amigos ;) y laboral (para que te pagan).
NO es apropiado desear "acelerar la superación" de un escalón...
En general: muchos de los conceptos de los que hablamos en Tecnología DE
Objetos, son "fáciles de entender", muy simples, pero lleva mucho tiempo
aprender a hacerlos prácticos (que dejen de ser "teoría"). Lleva mucho
tiempo pues incluye el aprendizaje de técnicas que no son aplicables con
herramientas tradicionales.
Escalones en la aplicación de la Tecnología de Objetos.
A.- Uso del ambiente de modo tradicional.
Aquí tenemos en un ambiente como Smalltalk, un conjunto de herramientas de
producción muy potente logrando una velocidad de producción muy interesante,
pero solo 2 o 3 veces superior a otras herramientas tradicionales (basadas
en Pascal, Basic o Java).
En este escalón se usa Smalltalk como un lenguaje de programación con muy
buenos tools y frameworks de base.
Se usan componentes (no objetos) con todas las posibilidades de uso que
brindan los componentes y las arquitecturas de software y las de reuso que
brindan los frameworks abiertos (que dan mucha mas potencia que los
componentes de caja negra).
Aquí se acostumbra a escribir código y a utilizar herramientas de generación
de código.
Se utiliza la clasificación y delegación aunque a menudo de forma
inadecuada.
A menudo se confunde uso con reuso. (componente con objeto, clase con
especie, y evolución con desarrollo incremental)
Los problemas que están fuera del alcance en este escalón:
1.- escalabilidad.
2.- crecimiento desproporcionado de la complejidad del sistema con el
volumen del sistema.
3.- estar satisfecho con el reuso (tal como se entiende en esta etapa)
4.- dependencia de las individualidades de un grupo.
5.- obsolescencia del producido.
6.- [seguro hay mas...]
B.- Uso del Ambiente para "desarrollo personal".
Inmediatamente después de superar el dominio (en el uso) de los frameworks
de base; ocurre que uno empieza a desarrollarse técnicamente y a lograr
distinguirse en la construcción de herramientas (escribiendo código) e
incluso plantear "mejoras" a las herramientas de base.
Muchas veces esta etapa se intenta abordar sin superar la anterior y es muy
común escuchar planteos de "mejoras" que no lo son (por falta de experiencia
en la primera etapa).
El Ambiente como modelo de producción es como una lente, una lupa que
permite focalizar el desarrollo personal (ver paper de Daniel H. H. Ingalls
en http://www.smalltalking.net/Papers/stDesign/stDesign.htm ).
Pero esta lente tan conveniente al comienzo de esta etapa es la que no
permite el paso al próximo escalón...
Esta etapa (la mas gruesa) es la que permite construir un modelo robusto de
producción, pero que también potencia la arrogancia y muchas veces no
permite ver mas allá de lo que uno aprendió.
Los problemas que están fuera del alcance en este escalón:
1.- estabilidad (se siente que lo de ayer no cuenta, porque mañana
tenemos una versión mejor).
2.- escalabilidad (solo se puede hacer lo posible de realizar con "una
cabeza por persona")
3.- independencia de personal.
4.- portabilidad (generalmente son etapas de alto fanatismo y
conocimiento de solo una versión de smalltalk).
5.- sorprender en las soluciones (solo en la etapa siguiente se logra
trabajar "sin sorprender", fundamental en la producción de software de
volumen)
C.- Uso del Ambiente como la suma de sus partes.
Recién con la posibilidad de participar en varios proyectos (no solo
personales) aparece la problemática de la instanciacion de soluciones en
distintos contextos/dominios, etc.
Aquí es donde empieza a aparecer la necesidad de NO escribir código.
Es donde empieza a percibirse la realidad virtual de un sistema y empieza a
valorarse el que un sistema sea un conjunto de objetos (no un conjunto de
clases que lo definen, ni un conjunto de métodos que lo hacen funcionar...)
La problemática de "pegar la experiencia" hecha en distintos dominios hace
concreta la necesidad de trabajar con objetos.
El pegar la experiencia es una búsqueda sin fin y es un objetivo un tanto
inocente, el cual se logra contener al final de esta etapa.
En esta etapa, creo que la persona está realmente apta como para empezar a
enseñar objetos (aunque debo ser sincero y decir que no conozco personas que
hayan llegado a este escalón y estén enseñando...).
En este escalón se entiende que hay "algo" en Smalltalk que no existe en las
otras alternativas y que uno no podría hacer lo mismo en algo que no sea un
ambiente. Aunque veo que la mayoría de la gente no sabe que es ese "algo",
ni puede definirlo pues cada vez que lo hace "bajando" el concepto a lo
técnico, encuentra con que ese algo desapareció, ese reduccionismo de
llevarlo a lo técnico haca desaparecer el efecto...
En esta etapa se entiende que el poder que tiene eso de que en Smalltalk
"todo es un objeto", pero aún no se entiende que hayan cosas que no son
objetos, aunque todo lo contenido en el Ambiente sean objetos...
(fijense que la frase "todo es un objeto" se conoce el primer día, pero
forma parte de la teoría hasta este punto)
En esta etapa es fundamental trabajar en grupos y a diario en el ambiente,
produciendo "todo" en el ambiente.
Aquí se hace práctico el uso de reflexión, introspección y transparencia
(aunque a veces en la etapa anterior ya se usan
informalmente/"inteligentemente" ;).
D.- Uso del Ambiente como un Ambiente.
Aquí se produce un "flash!", se hace concreta la idea de que un ambiente no
es solo lo que contiene, que un sistema es abierto y etc...
Se aprende a construir sistemas abiertos y se entienden las técnicas que uno
aprendió a utilizar en las etapas anteriores (trabajando en grupo, etc.).
Aquí se entiende que la Tecnología de Objetos es de Objetos (no solo
virtuales!) y que los sistemas no son solo simulaciones de una realidad,
sino que son también la realidad. Además se "siente" que el Ambiente no es
solo la suma de sus partes (ni solo los objetos que contiene). El Ambiente
no es solo el ambiente de objetos virtuales, sino que es además "Medio
Ambiente", el medio y soporte de un sistema (virtual, real, informático,
etc.).
En esta etapa se hace realmente útil el uso de técnicas de metaprogramación.
Solo acá se hace clara la ventaja de usar objetos y no escribir código
(forma parte de la teoría la ventaja, antes se vive como una expresión de
deseo; en esta etapa se sabe discernir donde ubicar el limite y uno utiliza
ese límite como una herramienta más).
E.- Realimentación con profesionales vírgenes.
Aquí se esta preparado para empezar de nuevo el camino.Si es posible a
diario, y nutriéndose de quienes son vírgenes en la tecnología.
Ayudando a los que están en las otras etapas, pero no para enseñar, sino
para acompañar. Se uno que acompaña el camino, no para marcar lo "correcto",
sino para compartir las innumerables alternativas que presenta cada sistema
en un instante.
Para reforzar el desarrollo en cada etapa es fundamental la existencia de un
ámbito donde se hable de esta tecnología a diario y que además convoque con
actividades frecuentes a poderse desarrollar usando la tecnología, tanto en
ámbitos de informática como de servicio a otros profesionales.
Ese lugar es Smalltalking y quienes estamos aquí, disfrutamos muchisimo el
escribir, hablar y leer mails como este !
un cordial saludo,
Ale.
----- Original Message -----
From: "Osvaldo Aufiero" <osvaldoa@...>
To: <smalltalking@...>
Sent: Monday, September 02, 2002 9:03 PM
Subject: RE: [objetos] Dolphin 4.0. // nuevas consultas.
> Hola Ale, podrías explicar un poco más esto por favor?
>
> > Construir un sistema de objetos, es crear objetos, no escribir código.
> (al decir crear objetos, estamos diciendo objetos...
> que no sean de la clase CompiledMethod ;-)
>
> Gracias
>
> Osvaldo
>
>
>
>
> Para retirarse del grupo,
> puede enviar un email a:
> smalltalking-unsubscribe@egroups.com
>
>
> Tu uso de Yahoo! Grupos está sujeto a las
http://ar.docs.yahoo.com/info/utos.html
>
>
>
Hola lista,
prodrian darme una mano con un problema que tengo con un programita
de prueba que estoy haciendo en VA60(trial) , en el development
environment todo funciona muy bien , pero al crear el ejecutable
parte del programa no funciona.
Basicamente lo que hago es conectarme a un RDBMS y correr un sql,
esto devuelve anAbtResultTable, luego creo una anOrderedCollection y
le agrego todos los registros de anAbtReultTable asi:
anAbtResultTable do:[ :rec | anOrderedCollection add: rec].
luego para mostrar las filas tengo en una ventana un comboBox y le
asigno sus items asi:
(self subpartNamed: 'Combo Box1') items: anOrderedCollection.
el atributo "attributeName" del comobox es NYAP que es la columna del
registro que tiene que visualizarce en el combo.
Como lo dije antes, en el development environment todo funciona muy
bien , pero al crear el ejecutable, en el combo box en vez de
aparecer el valor de NYAP aparece "attribute NYAP doesnot exist".
alguien se encontro con este problema alguna vez? como lo
solucionaron?
desde ya gracias
Hugo
Gracias por la explicación Ale, creo que me faltan algunos proyectos
para darme cuenta de algunas cosas... Gracias de nuevo
Osvaldo
-----Mensaje original-----
De: Alejandro F. Reimondo [mailto:aleReimondo@...]
Enviado el: Martes, 03 de Septiembre de 2002 09:01 p.m.
Para: smalltalking@...
Asunto: Re: [objetos] Dolphin 4.0. // nuevas consultas.
Hola Osvaldo,
Aprender a trabajar con Objetos no es fácil (aprender a trabajar solo
Orientado a Objetos es muy fácil, hay muchos manuales metodologías
propuestas, etc. ;).
Lo mas sorprendente es que uno siempre piensa por un lado que "aprendió
todo" y por otro que puede mejorar solo "un poquito mas".
Esto hace que el camino del aprendizaje sea muy entusiasmante, pero
también
hace que uno pueda no darse cuenta cuando deja de avanzar en el
aprendizaje... y equivocadamente pensar que es la mejor manera en la que
puede trabajar la que actualmente conoce (esto no solo pasa a personas
sino
a empresas y organizaciones que invierten poco en la capacitación
tecnológica).
A continuación voy a comentar algunos "escalones" que tiene el
aprendizaje
del trabajo con Objetos.
La superación de esos escalones es un desafío personal y está
condicionado a
las oportunidades de realización dadas por el contexto social (quienes
sean
tus amigos ;) y laboral (para que te pagan).
NO es apropiado desear "acelerar la superación" de un escalón...
En general: muchos de los conceptos de los que hablamos en Tecnología DE
Objetos, son "fáciles de entender", muy simples, pero lleva mucho tiempo
aprender a hacerlos prácticos (que dejen de ser "teoría"). Lleva mucho
tiempo pues incluye el aprendizaje de técnicas que no son aplicables con
herramientas tradicionales.
Escalones en la aplicación de la Tecnología de Objetos.
A.- Uso del ambiente de modo tradicional.
Aquí tenemos en un ambiente como Smalltalk, un conjunto de herramientas
de
producción muy potente logrando una velocidad de producción muy
interesante,
pero solo 2 o 3 veces superior a otras herramientas tradicionales
(basadas
en Pascal, Basic o Java).
En este escalón se usa Smalltalk como un lenguaje de programación con
muy
buenos tools y frameworks de base.
Se usan componentes (no objetos) con todas las posibilidades de uso que
brindan los componentes y las arquitecturas de software y las de reuso
que
brindan los frameworks abiertos (que dan mucha mas potencia que los
componentes de caja negra).
Aquí se acostumbra a escribir código y a utilizar herramientas de
generación
de código.
Se utiliza la clasificación y delegación aunque a menudo de forma
inadecuada.
A menudo se confunde uso con reuso. (componente con objeto, clase con
especie, y evolución con desarrollo incremental)
Los problemas que están fuera del alcance en este escalón:
1.- escalabilidad.
2.- crecimiento desproporcionado de la complejidad del sistema con
el
volumen del sistema.
3.- estar satisfecho con el reuso (tal como se entiende en esta
etapa)
4.- dependencia de las individualidades de un grupo.
5.- obsolescencia del producido.
6.- [seguro hay mas...]
B.- Uso del Ambiente para "desarrollo personal".
Inmediatamente después de superar el dominio (en el uso) de los
frameworks
de base; ocurre que uno empieza a desarrollarse técnicamente y a lograr
distinguirse en la construcción de herramientas (escribiendo código) e
incluso plantear "mejoras" a las herramientas de base.
Muchas veces esta etapa se intenta abordar sin superar la anterior y es
muy
común escuchar planteos de "mejoras" que no lo son (por falta de
experiencia
en la primera etapa).
El Ambiente como modelo de producción es como una lente, una lupa que
permite focalizar el desarrollo personal (ver paper de Daniel H. H.
Ingalls
en http://www.smalltalking.net/Papers/stDesign/stDesign.htm ).
Pero esta lente tan conveniente al comienzo de esta etapa es la que no
permite el paso al próximo escalón...
Esta etapa (la mas gruesa) es la que permite construir un modelo robusto
de
producción, pero que también potencia la arrogancia y muchas veces no
permite ver mas allá de lo que uno aprendió.
Los problemas que están fuera del alcance en este escalón:
1.- estabilidad (se siente que lo de ayer no cuenta, porque mañana
tenemos una versión mejor).
2.- escalabilidad (solo se puede hacer lo posible de realizar con
"una
cabeza por persona")
3.- independencia de personal.
4.- portabilidad (generalmente son etapas de alto fanatismo y
conocimiento de solo una versión de smalltalk).
5.- sorprender en las soluciones (solo en la etapa siguiente se
logra
trabajar "sin sorprender", fundamental en la producción de software de
volumen)
C.- Uso del Ambiente como la suma de sus partes.
Recién con la posibilidad de participar en varios proyectos (no solo
personales) aparece la problemática de la instanciacion de soluciones en
distintos contextos/dominios, etc.
Aquí es donde empieza a aparecer la necesidad de NO escribir código.
Es donde empieza a percibirse la realidad virtual de un sistema y
empieza a
valorarse el que un sistema sea un conjunto de objetos (no un conjunto
de
clases que lo definen, ni un conjunto de métodos que lo hacen
funcionar...)
La problemática de "pegar la experiencia" hecha en distintos dominios
hace
concreta la necesidad de trabajar con objetos.
El pegar la experiencia es una búsqueda sin fin y es un objetivo un
tanto
inocente, el cual se logra contener al final de esta etapa.
En esta etapa, creo que la persona está realmente apta como para empezar
a
enseñar objetos (aunque debo ser sincero y decir que no conozco personas
que
hayan llegado a este escalón y estén enseñando...).
En este escalón se entiende que hay "algo" en Smalltalk que no existe en
las
otras alternativas y que uno no podría hacer lo mismo en algo que no sea
un
ambiente. Aunque veo que la mayoría de la gente no sabe que es ese
"algo",
ni puede definirlo pues cada vez que lo hace "bajando" el concepto a lo
técnico, encuentra con que ese algo desapareció, ese reduccionismo de
llevarlo a lo técnico haca desaparecer el efecto...
En esta etapa se entiende que el poder que tiene eso de que en Smalltalk
"todo es un objeto", pero aún no se entiende que hayan cosas que no son
objetos, aunque todo lo contenido en el Ambiente sean objetos...
(fijense que la frase "todo es un objeto" se conoce el primer día, pero
forma parte de la teoría hasta este punto)
En esta etapa es fundamental trabajar en grupos y a diario en el
ambiente,
produciendo "todo" en el ambiente.
Aquí se hace práctico el uso de reflexión, introspección y transparencia
(aunque a veces en la etapa anterior ya se usan
informalmente/"inteligentemente" ;).
D.- Uso del Ambiente como un Ambiente.
Aquí se produce un "flash!", se hace concreta la idea de que un ambiente
no
es solo lo que contiene, que un sistema es abierto y etc...
Se aprende a construir sistemas abiertos y se entienden las técnicas que
uno
aprendió a utilizar en las etapas anteriores (trabajando en grupo,
etc.).
Aquí se entiende que la Tecnología de Objetos es de Objetos (no solo
virtuales!) y que los sistemas no son solo simulaciones de una realidad,
sino que son también la realidad. Además se "siente" que el Ambiente no
es
solo la suma de sus partes (ni solo los objetos que contiene). El
Ambiente
no es solo el ambiente de objetos virtuales, sino que es además "Medio
Ambiente", el medio y soporte de un sistema (virtual, real, informático,
etc.).
En esta etapa se hace realmente útil el uso de técnicas de
metaprogramación.
Solo acá se hace clara la ventaja de usar objetos y no escribir código
(forma parte de la teoría la ventaja, antes se vive como una expresión
de
deseo; en esta etapa se sabe discernir donde ubicar el limite y uno
utiliza
ese límite como una herramienta más).
E.- Realimentación con profesionales vírgenes.
Aquí se esta preparado para empezar de nuevo el camino.Si es posible a
diario, y nutriéndose de quienes son vírgenes en la tecnología.
Ayudando a los que están en las otras etapas, pero no para enseñar, sino
para acompañar. Se uno que acompaña el camino, no para marcar lo
"correcto",
sino para compartir las innumerables alternativas que presenta cada
sistema
en un instante.
Para reforzar el desarrollo en cada etapa es fundamental la existencia
de un
ámbito donde se hable de esta tecnología a diario y que además convoque
con
actividades frecuentes a poderse desarrollar usando la tecnología, tanto
en
ámbitos de informática como de servicio a otros profesionales.
Ese lugar es Smalltalking y quienes estamos aquí, disfrutamos muchisimo
el
escribir, hablar y leer mails como este !
un cordial saludo,
Ale.
----- Original Message -----
From: "Osvaldo Aufiero" <osvaldoa@...>
To: <smalltalking@...>
Sent: Monday, September 02, 2002 9:03 PM
Subject: RE: [objetos] Dolphin 4.0. // nuevas consultas.
> Hola Ale, podrías explicar un poco más esto por favor?
>
> > Construir un sistema de objetos, es crear objetos, no escribir
código.
> (al decir crear objetos, estamos diciendo objetos...
> que no sean de la clase CompiledMethod ;-)
>
> Gracias
>
> Osvaldo
>
>
>
>
> Para retirarse del grupo,
> puede enviar un email a:
> smalltalking-unsubscribe@egroups.com
>
>
> Tu uso de Yahoo! Grupos está sujeto a las
http://ar.docs.yahoo.com/info/utos.html
>
>
>
Para retirarse del grupo,
puede enviar un email a:
smalltalking-unsubscribe@egroups.com
Tu uso de Yahoo! Grupos está sujeto a las
http://ar.docs.yahoo.com/info/utos.html
On Tuesday 03 September 2002 21:01, you wrote:
>
> Escalones en la aplicación de la Tecnología de Objetos.
>
> A.- Uso del ambiente de modo tradicional.
...
> A menudo se confunde uso con reuso. (componente con objeto, clase con
> especie, y evolución con desarrollo incremental)
Alejandro, podrias profundizar en como se confunden estos conceptos?
German.
Enviar correo