Metodos de implementación opcional?

[Pablo Zebraitis]

Alguno tiene una idea como hacer algo asi?

Tego unas base clases (un API SCALA para VAADIN) que deseo no sean ABSTRACT, hay ciertos métodos que quiero dejar con una implementación OPCIONAL, NO INDEFINIDOS, no quero OBLIGAR al que extienda a implementarlos.

def xxxx = {}

para que dentro de esta clase (si están implementados) ESTO ES LO QUE QUIERO EVALUAR Y NO SE COMO, haser cosas, activar ACTIONS etc...

a alguno se le ocurre algún workarround?

gracias. saludos.

[Gabriel Claramunt]

Traits no andarian?

Algo como:

class CoreFunctionality {

...funciones que van si o si...

}

trait ExtraFunctions {

 ... funciones extra (ya implementadas o abrstract )...

}

class  FullClass extends CoreFunctionality with ExtraFunctions (o abstract class... si el trait no tiene implementacion)

Que opinan?

2013/1/31 Pablo Zebraitis <pa...@zebraitis.com>

--
Has recibido este mensaje porque estás suscrito al grupo "Scala Users Group Uruguay" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a scala-users-group-...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--
Gabriel Claramunt
Twitter: @gclaramunt

[Tomás Lázaro]

Yo agregaría un self typing a las trait que dice Gabriel y capaz habría que meter algún 'abstract override' dependiendo lo que quieras lograr. 

Podrías poner código posta para ver bien eso?

[Tomás Lázaro]

No sé para que quería enchufar abstract overrides... 

[Germán Ferrari]

Buenas,

La verdad no me termina de quedar claro el problema, capaz que un ejemplo más largo ayuda.

Saludos,

Germán

2013/1/31 Pablo Zebraitis <pa...@zebraitis.com>

--

[Pablo Zebraitis]

Hola a todos nuevamente. para continuar con mi inquietud, estuve leyendo un poco post relacionados conesto como:

http://www.scala-lang.org/node/3496

Pero en la idea que venía manejando sería algo como:

abstract class x {

 var someAction: Option[Unit] // no quisiera que fuera mandatorio implementar.

    def initComponents() {

       ....

       someActionComponent.setVisible(someAction.isDefined)

       ....

   }

  combo.addListener(new ValueChangeListener {

    def valueChange(event: ValueChangeEvent) {

      if (someAction.isDefined } someAction()

   }

  })

}

Tal vez lo que estaba buscando era algo como en:

http://specs.googlecode.com/svn-history/r1303/docs/scaladocs-1.6.2.1/org/specs/specification/BeforeAfter.html

pero siguiendo la misma linea expuesta en: http://jim-mcbeath.blogspot.com/2010/09/scala-coroutines.html

estaría bueno poder definir:

Method Summary
def	doAfter (actions : => Any) : scala.Option[Unit] adds an "after" function to the last sus being defined

class x {

 def @optional someAction

 def initComponents() {

 ....

 someActionComponent.setVisible(someAction.isDefined)

 ....

 }

}

Con el objetivo (secundario pero comodo) que los IDEs pudieran ofrecer su implementación.. opcional, 

pero principalmente para que sea bien clara la intención y no realizarlo a través de un workaround.

Bueno, el fin era para discutir alguna de esas divagantes ideas que se nos ocurren al disfrutar desarrollando con esta maravillosa herramienta.

Saludos a todos. 

On Wednesday, February 6, 2013 7:56:19 AM UTC-2, Germán wrote:

Buenas,

La verdad no me termina de quedar claro el problema, capaz que un ejemplo más largo ayuda.

Saludos,

Germán

2013/1/31 Pablo Zebraitis <pa...@zebraitis.com>

Alguno tiene una idea como hacer algo asi?

Tego unas base clases (un API SCALA para VAADIN) que deseo no sean ABSTRACT, hay ciertos métodos que quiero dejar con una implementación OPCIONAL, NO INDEFINIDOS, no quero OBLIGAR al que extienda a implementarlos.

def xxxx = {}

para que dentro de esta clase (si están implementados) ESTO ES LO QUE QUIERO EVALUAR Y NO SE COMO, haser cosas, activar ACTIONS etc...

a alguno se le ocurre algún workarround?

gracias. saludos.

--
Has recibido este mensaje porque estás suscrito al grupo "Scala Users Group Uruguay" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a scala-users-group-uruguay+unsub...@googlegroups.com.

[Gabriel Claramunt]

De cierta forma tiene sentido hacerlo asi como lo estas haciendo :)

Lo que se me viene a la mente: 

Si pones Option[Unit]= {... <mi codigo con side effects>... } se va a ejecutar solamente cuando incialize la clase, creo que lo que precisas es o usar def o Option[=>Unit] y como me imagino que la accion a tomar eventualmente necesita conocer el evento, por lo que seria def someAction(ev:ValueChangeEvent):Option[Unit] o var someAction:ValueChangeEvent=>Option[Unit] y en la llamada a someAction, le pasas el evento:  if (someAction.isDefined } someAction(event)

Por ultimo, si queres dejarlo indefinido por defecto, haces simplemente que devuelva 'None': someAction(ev:ValueChangeEvent):Option[Unit]=None me parece que se acerca bastante a lo que queres, no?

2013/2/12 Pablo Zebraitis <pa...@zebraitis.com>

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a scala-users-group-...@googlegroups.com.

Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

[Pablo Zebraitis]

Uniendo creo que quedaría algo como:

/**

 * Created by pablo

 * Date: 2013-02

 */

abstract class x {

  val button = new JButton()

  val optionalAction: Option[ActionEvent => Unit] = None

  def initComponents() {

    // ....

    button.setVisible(optionalAction.isDefined)

    // ....

  }

  button.addActionListener(new ActionListener {

    def actionPerformed(ae: ActionEvent) { optionalAction.get(ae) }

  })

}

esto te parece que funcaría?

Saludos!

2013/2/12 Pablo Zebraitis <pa...@zebraitis.com>

2013/1/31 Pablo Zebraitis <pa...@zebraitis.com>

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a scala-users-group-uruguay+unsubsc...@googlegroups.com.

Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--
Has recibido este mensaje porque estás suscrito al grupo "Scala Users Group Uruguay" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a scala-users-group-uruguay+unsub...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--
Gabriel Claramunt
Twitter: @gclaramunt

[Gabriel Claramunt]

excepto que cuando tenes None, el get te explota :)

Tendria que ser: optionalAction.map( f=>f(ae))

2013/2/12 Pablo Zebraitis <pa...@zebraitis.com>

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a scala-users-group-...@googlegroups.com.

Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

[fedesilva]

On Wednesday, February 13, 2013 1:00:22 AM UTC-2, Gabriel Claramunt wrote:

excepto que cuando tenes None, el get te explota :)

Tendria que ser: optionalAction.map( f=>f(ae))

o foreach si no te interesa el resultado y si los side effects

 

2013/2/12 Pablo Zebraitis <pa...@zebraitis.com>

--
Gabriel Claramunt
Twitter: @gclaramunt

--
Has recibido este mensaje porque estás suscrito al grupo "Scala Users Group Uruguay" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a scala-users-group-uruguay+unsub...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

[Germán Ferrari]

2013/2/13 fedesilva <fede....@gmail.com>

On Wednesday, February 13, 2013 1:00:22 AM UTC-2, Gabriel Claramunt wrote:

excepto que cuando tenes None, el get te explota :)

Tendria que ser: optionalAction.map( f=>f(ae))

o foreach si no te interesa el resultado y si los side effects

 

Iba a comentar algo parecido. Yo me acostumbré a usar siempre el  foreach en estos casos después de haber sido "mordido" por usar map solo para ejecutar side-effects trabajando con colecciones no-estrictas. En esos casos la función que se pasa al map no se ejecuta hasta que se accede a los elementos, lo cual puede no suceder nunca...

 

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a scala-users-group-...@googlegroups.com.