----------
From: Stephan Nagy snagy@web-publicity.com
To: ECS ecs@list.working-dogs.com
Subject: Re: ECS API
Date: Tue, May 18, 1999, 9:56 PM


>- No real polymorphism in the addElement method. I want to have a method
>that returns an Element container object which can then have other
>elements added to it without really knowing what it is. Because
>ElementContainer and all the subclasses of MultiPartElement redefine
>their own addElement() method rather than overriding one defined in a
>superclass, I can't do this. Presumably things have been done this way
>to allow the "interesting" shorthand syntax for setting properties and
>such,

Thats right.

>but a) is it worth sacrificing a great deal of power and
>flexibility for,

Nothing is really lost addElement() is just a wrapper arround
addElementToRegistry() that returns a specfic type of element.  This was a
concious choice that we debated for about 3 weeks.

>and b) are you sure you should be encouraging this kind
>of  syntax in Java programs?

Normally no I wouldn't want to encourage this kind of syntax in java
programs, but doing it this way allows us to do method chaining to make
initialization of an element easier.

>[I suppose addElementToRegistry() could be used here instead to achieve
>this(?), But it would be nasty to have to type that one out a few dozen
>times in a method]

Yes thats how you would do it.  You could create your own wrapper method.

>- A lot of your method names seem to be much longer than they need to
>be. addElement() for example - why can't it just be add(), given that it

I agree the names are long, perhaps longer than is necessary, but i'm a fan
of descriptive method names.

>is would be defined as add(Element element) it should be pretty obvious
>what is supposed to be added.

we currently have several different add* methods and more will be added in
the future thats why they have descriptive names.

>This would make code simpler to read and easier to type.

IMO easier to type and harder to maintain ( at least for me ).

>[BTW: why isn't MultiPartElement a descendant of ElementContainer? Can't
>all multipart elements be thought of as containers? ]

I'm not a big fan of the *PartElements the only difference between them in
our implementation is if they need to have a closing element defined /
ElementContainer extends ConcreteElement which is the Concrete
implementation of the Element class, as it stands now every element in ecs
can have another added to it,  it just has to have the addElement() method
defined for method chaining otherwise you would have to use
addElementToRegistry.

>This is not meant to be a flame in any way - just constructive criticism

Constructive Criticism (and patches) are always welcome.  ECS is still in
it's infancy and the api still needs alot of improvements/additions.  I
haven't been able to spend very much time on it as of late,  but once i
finish getting moved i should have some more free time to devote to it.

>:-) you guys have definitely done some great work here on ECS!

Thank you.

-stephan