Topics < PROBRAL/InternalArea

TWiki webs: Main | TWiki | Sandbox Log In or Register

Topics from Mira & Vaidas:

1. Making virtual classes/deep mixin composition more dynamic so that they could express dynamic features. Then dynamic features would be described as dynamic layers of partial definitions of classes. Dynamic virtual classes would present an alternative to wrappers and dynamic aspects in CaesarJ. The challenge here would be both the technical implementation of the dynamic composition semantics, as well as guaranteeing type-safety of such constructs.

- For a better support of interfaces between features, it introduces "require" inheritance relationship and so allows to differentiate between features providing and requiring an interface. The completeness checking of classes has been adjusted to check if in the compositions defining concrete products all required interfaces are provided.

- Mixin composition semantics for event and state machines have been defined to enable decomposition of these behavioral abstractions by features. Abstract events are intended to enrich the interfaces between features.

2. There is certain duplication between virtual classes and the pointcut-advice mechanism in CaesarJ, because both of them can be used to extend or override existing methods. Also, as mentioned above, dynamic virtual classes would present an alternative to dynamic AO features. Thus a logical step would be to unify the two extension mechanisms. The result could be something like quantified overriding of methods, or pointcuts scoped by the enclosing family object.

3. In ECaesarJ we emphasize the importance of supporting events in interfaces, encapsulated definition of events, quantification over dynamic relationships between objects. I think that such kind of events could also be useful for describing dynamic features, because such features would be represented as objects (family objects) rather than classes, and related by dynamic relationships. Events would also be necessary to describe interfaces between such features. Late-bound events would be necessary to support dynamic composition of features using events of each other.

4. Escala: Our current development is EScala language, where we further elaborate the idea of events of object members (late-bound, a part of object's interface, respect encapsulation) as class members combined with the ideas of AOP (interception of implicit events) and functional reactive programming (declarative composition of events, push-based propagation of events). I uploaded our current tech report about EScala, which we are going to shorten and submit to the next AOSD. As you see, we use Scala as a basis for our latest language experiment. Actually, as a long term goal we are considering moving our language development on top of Scala rather than Java. All technical implications of this transition is not yet completely clear, but at least for events it worked quite well. We benefited from support for first-class functions and the rich type system of Scala. As the next step we consider moving virtual classes and propagating mixin composition to Scala. The advantage is that Scala already has virtual types and basic mixin composition.

5. Dependent classes. I also uploaded my PhD thesis, which presents various scenarios of variability management with virtual classes and dependent classes. Dependent classes are a generalization of virtual classes for multi-dispatch and are interesting for variation management because they allow parameterization and dynamic dispatch of classes (and groups of classes) by multiple variation points. The type system enables type-safe covariant dependencies between classes sharing certain variations. Now the variation points of a class must be independent, but maybe by generalizing the dispatch of dependent classes to something like predicate dispatch, we could also express various dependencies between variation points similar to feature constraints in the feature model. The DC_C calculus, presented in Sec. 5.3 could be used as a theoretical basis for such experiments. Also, we are thinking about using dependent classes to replace dynamic wrapper selection in CaesarJ, because a wrapper is a class depending on two objects: the enclosing family and the wrapped object.

6. Dynamic product lines Considering dynamic product lines, the most recent work is the work of my colleagues Tom and Ralf about dynamic feature models (I added a link to it in the Wiki), but my personal interest is to do something in connection with CaesarJ. Basically, the idea would be to go back to the roots of CaesarJ, because it started as a language for dynamically pluggable components/features, but try to unify and simplify language design (see the points from the previous e-mail).

Topics from Paulo:

1. Aspect interfaces for feature modularity. We have explored extensions of AspectJ and CaesarJ with notions of interfaces that support independent feature development and maintenance. This can be seen as language support for XPIs, but goes further than what can be expressed by XPIs. We could see how this would fit with ECaesarJ events, and go further by improving language design and implementation, besides exploring more significant case studies.

2. Dynamic product lines. I have seen at AOSD 2010 that you have a proposal for dynamic feature models and PLs, but I guess it basically assumes a 1:1 mapping between features and aspects that implement them. Due to feature interaction (not exactly the one you consider at the AOSD 2010 Dynamic PL paper), we work with a notion of configuration knowledge (and model checking) that supports more general mappings. But we have applied this only to static PLs, so it might be worth investigating how this would fit with your proposal for dynamic PLs. We can do the same with some idioms we have explored for implementing the same feature but with different binding times, extending the Edicts proposal.

3. Emergent feature modularity. This might be further away from the original proposal, but we are also exploring a tool based, rather than language based, approach for feature modularity. The idea is to provide better support than current tools for visual separation of concerns, as in Apel's work and in an Eclipse plugin Meantime has developed when they started working with us.

-- RodrigoAndrade - 12 Aug 2010

Parents: WebHome