cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [cforms] Forwarding: Explanation of derived classes
Date Mon, 05 Jan 2004 23:35:58 GMT

Timothy Larson wrote:

 > --- Marc Portier <> wrote:
 >> I saw a different mail for that, no?
 > Here are a couple emails:
 > Summary:
 >   We may want to parameterize "class" to allow it to define (or "new"
 >   to allow it to create) modified versions of a class, such as to give
 >   nested unions a different default case than their parents, or to add
 >   or remove widgets in nested widget structures.

this I trully don't get yet... and it more and more starts to feel like 
the crux?

again it yields my first reaction: isn't this going to break the 
'static' position the created 'definitions' and 'bindings' are taking up 
here and now?

(but I honestly don't understand)

 > Let me see if I can describe this more clearly.  In Java you can
 > define a class that extends another class to allow for additional,
 > modified, or restricted behavior.  This is the main concept I am
 > referring to when I mention derived classes.  I would like to be
 > able to create a class of widgets, and then be able to define
 > additional classes which extend the first class.

I think I'm missing the why?
any use case?

 > What may be throwing you is that I am mixing in an idea that is
 > not from Java.  Some languages allow "classes" to be specified by
 > example, rather than requiring a separate class definition.  Think
 > of it like being able to take an object *instance* and say:
 >   Object newObject = new oldObject();
 > to create a new object with the same variables and methods as the
 > oldObject instance.  Now add Java's concept of anonymous classes
 > to allow you to say:
 >   Object extendingObject = new extendedObject() {
 >     // Place extending variables and methods here
 >   }

sounds like js?

 > To bring this back to the cforms context, look at NewJXPathBinding
 > to see how it can create an "instance" (remember: really just an
 > object reference) of either a defined "class" or of another active
 > binding.  This is like the first example above, "new oldObject()".

uh, or?
the defined classBinding would have nested in it the other active 
Binding, no?

 > In general, I want to be able to take a "class" or an example
 > binding, definition, or template and be able to "extend" it either
 > while defining a new "class" or while creating an instance with
 > "new".  This last case, creating an extending object using "new",
 > is like the second example above, "new extendedObject() { }".

syntax example?

 > You are probably thinking, "What's this for?"  Classes are good
 > if you want to create more than one instance, or if you need to

which we are constantly inside woody? the tree of widget-definitions 
serves as the 'class' from which you can instantiate...

 > specify the definition (e.g. for interfacing reasons) separate
 > from creating the instance data.  When your use case does not have
 > either of these requirements, being forced to define a class is
 > syntactic overhead, slowing you down and cluttering your code.

I don't get this at all: nobody is forced to use class and new?

 > Similarly, if you will never need to reference a class's name
 > except to create the only instance of the class, then having
 > support for anonymous classes can cut the overhead of having to
 > create and maintain a non-conflicting name for the class.

uh, but that sounds precisely like what I was suggesting previously with 
the all-in-one class-struct with new? (see other mail)

only thing still missing then would be to allow for the <new> to support 
some 'extend' by adding to it specific children?

which would require
1/ not referencing but 'cloning' a created classNode!
2/ allow (possibly in that cloning process) to override/extend already 
set features of that classNode

to allow for the cloning/extending of the private-finals we could be 
adding some copy-constructors to each of the nodes that can be 'extended'

class SomeNode {
   private final SomeFeature x;
   private final OverridableFeature y;

   public SomeNode(SomeFeature x) {
     this(x, null);

   public SomeNode(SomeFeature x, OverridableFeature y) {
     this.x = x;
     this.y = y;

   public SomeNode(SomeNode prototype, OverridableFeature y) {
     this.x = protoype.x;
     this.y = y;

and let the userNodes remain as descrived earlier: wrappers around these 
  re-used nodes... where the call to their setClassNode() would be more 
something like

class UserNode extends SomeNode{
   private final OverridableFeature y;
   private SomeNode myExtendedClassNode;

   public void setClassNode(SomeNode theClassNode) {
     if (this.myClassNode != null) throw ...;
     this.myExtendedClassNode = new SomeNode(theClassNode, this.y);

   public void someServiceMethod(...){

hm, but we don't want to duplicate the complete set of existing Node 
classes... again I'm getting tempted to believe that use-reuse is 
completely orthogonal to our widget-type system, and thus after removing 
'class' by suggesting an @type on node class we should maybe now take 
the logical next step and go for replacing the 'new' element with the 
@type-ref (earlier mentioned as @name)

hm, have to think some more...
comments welcome

 > Is this explanation clearer, or is you head spinning now?

can I reverse the question :-)

 >>>>>> - thinking also about proposing define/use in stead of class/new
 > We could do this name change, but what do you think in light of
 > the explanation given above?
 > --Tim Larson
 > __________________________________
 > Do you Yahoo!?
 > Find out what made the Top Yahoo! Searches of 2003

well, I'm afraid there is some dependency between my last three posts 
(allthough in different threads...)

hope to have given some food for thought here, next two days I'll be at 
customer's offices which offers me only mail-out and browsing

I'll do my best to keep up with the discussion but will most likely have 
limited time and means to participate until thursday, don't let that put 
you off to point out the flaws in my reasoning...

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message