avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: excalibur package naming (RE: [VOTE] Should Command be a sub of event?)
Date Fri, 05 Apr 2002 13:30:10 GMT


> From: Peter Donald [mailto:peter@apache.org]
> 
> On Fri, 5 Apr 2002 18:11, Leo Sutic wrote:
> > > From: Leo Simons [mailto:leo@leosimons.com]
> > >
> > > > Still trying to figure out whether this is an April Fool's joke
> > > > that started two days ago, but I'd like to make a case for
> > > > boredom, three-piece suits (gray ones) propose:
> > > >
> > > >          excalibur.system -> excalibur.container
> > >
> > > The thread was started because we have a problem: excalibur can
> > > contain multiple implementations of component managers, systems,
> > > event packages, commands, etc.
> >
> > That is a problem of arranging code into packages and subpackages,
> > not one of naming the packages. See below for how I want it done.
> >
> > ExcaliburComponentManager was actually a good name, since it was
> > *the* ComponentManager implementation for all of Excalibur.
> 
> *bzzt* wrong
> 
> I have never used ECM but regularly use excalibur packages. It 
> happens to be 
> *a* CM that is contained in excalibur but it is just one of three. 

Phoenix is a complete application and a project in itself. You can 
not compare a set of components like Excalibur to Phoenix. I would
expect the CM in Tomcat to be called TomcatComponentManager. I would
expect the servlet manager to be called TomcatServletManager or somesuch.
I would not expect the javax.servlet.Servlet interface to be renamed 
javax.servlet.AlleyCat. Or animals.furry.AlleyCat or animals.furry.Servlet.

> > As opposed to:
> >
> >     SingleThreadedComponentManager
> >     NetworkComponentManager
> >     SOAPComponentManager
> >
> > What is easier?
> 
> Bad examples. Implementations are rarely done this way. They usually 
> implement the same features in different ways. Consider Phoenix, ECM, 
> Fortress and Merlin - all of them basically do the same thing (act as a 
> container for components). 

Yes, but the implementations in Phoenix are not supposed to be used in
other projects. They are leaves in the class hierarchy. I never
expect to download Phoenix and separate out parts of it for use
in my own project the same way as I would with code in Excalibur.

The ContainerManager is specifically designed to be used in other 
projects. Phoenix isn't. Not in the same way.
 
> I would love to see you come up with a name for each of them that is 
> representative and would be clear to users.

As I stated above, Merlin is only supposed to be
used inside Phoenix. I could not care more about that name than I'd
care about the exact names of classes inside JBoss. *But* I would 
care about it if it were part of the API to Phoenix or JBoss. As it is now,
the only thing applications in Phoenix will see is the ComponentManager
interface. Which, as you notice, is descriptive.

As I stated in a mail to Berin, if "fortress" had been an engineering 
term describing what we now call a "container manager", then I would be
+1000 for calling the package "fortress". But it isn't and I am not.
 
> > Suppose a newbie to Excalibur is looking for a CM with the properties
> > above and is faced with the JavaDoc for Excalibur. Where does he/she
> > start looking for the CM implementation? You are basically forcing the
> > newbie to read the package descriptions instead of just scanning the
> > package names.
> 
> The same could be said of using names like Cocoon or Xerces for projects. 

Or using Apache for a software foundation. But why do we give
classes descriptive names? Why do we call the component manager 
interface "ComponentManager" and not "KingArthur"? Proper names 
work fine for projects, but at a certain level it becomes unmanageable.
That level is when the name must have a formal engineering definition, or
when you expect to often be able to pick one class/interface out from many
based on a guessing a name for a class with the sought-for properties.

Why is EJB classes in javax.ejb and not in javax.coffeemachine? (Get it?
*Enterprise* level java beans? Big stuff? Not just a regular coffeepot
but a *machine*? Ain't I *clever*? No.)

Why is it, that in every commercial grade API or set of classes there
is absolutely no messing around with the type of naming that
you apparently in complete seriousness propose?

I do not know what experience you have with commercial grade development,
or dealing with the people in charge of such, but the *only* way Avalon 
and Excalibur will be used in the real world by real companies
is to write the code in such a way as to make it usable in a commercial
environment. That means:

  + No cutesy-wutesy naming. No hackish-fun oh-god-how-clever-I-am stuff.
    You are not fun. I am not fun. We are not clever in the slightest. 
    No one is laughing or appreciating our homage to Arthurian legend.
    Because it is not fun or clever to kill maintainability.
  + Strict adherence to accepted engineering terms whenever applicable.
    If none is instantly applicable, derive a new one but make sure that
    it can be understood by someone only familiar with the words it
    were derived from. (I.e. initialize -> Initializable.initialize (), 
    absolutely not initialize -> BraveElvenWarrior.attack ())
  + Consideration for people who do not have time to learn all the
    code. Face it, most of the time is spent maintaining code. If you have:

    Bedazzling Names: Choose variable names with irrelevant emotional 
                      connotation. e.g.: 
                         marypoppins = (superman + starship) / god; 
                      This confuses the reader because they have difficulty 
                      disassociating the emotional connotations of the words 
                      from the logic they're trying to think about. 

    (Taken from http://mindprod.com/unmain.html)

    You will not be able to maintain your code base. Each non-descriptive
    name means one more mapping name->whatItReallyIs that must be in the
    head of the coder before he/she can do something. That coder 
    will not be the one that originally wrote the code.

Getting all medieval on the package names would mark Avalon as a closed
little geeky project for the spooky kids brigade of people hopelessly 
lost in AD&D to the extent that they can not separate role-playing from 
reality. 

              *It* *will* *not* *be* *taken* *seriously.* 

Period. Your battle for mindshare will be lost to some other project that
manages to appear as being more professional. Compared to an apparent horde of 
mentally retarded juvenile coders, that will not be difficult. It will not matter
one iota that...

  + ...Avalon, quite frankly, kicks ass on a massive scale.

  + ...that every piece of code in Avalon is industrial-grade and
       developed more in line with professional software practices
       than I'd say 90% of all code in existence.

  + ...that Avalon probably is superior to most other frameworks 
       out there.

                        *We* *will* *lose.*

Imagine an architect trying to get the next project to use Avalon. The CTO
is *very* wary about using open source, knowing that 95% of everything
is crap. Now, the architect has to convince the CTO that Avalon is
within the other 5%. He will not have the time to prove that Avalon
works. He will not have the time to demonstrate Cocoon or JAMES or
any other successful project. He may list successful projects, but there
are other projects that have been successful using other frameworks 
(JBoss/JMX). After the third medieval term, the architect will be glad to
have a job. And the CTO would be right: Based on similarity with other
worthless hackish projects that are not commercial grade, he/she would be
right in assuming that Avalon is one of those and refusing to waste any
more time on it. 

> > We do not want several competing event packages.
> 
> yes we do. If we did not allow that then the ECM, fortress and Merlin 
> products would not exist because Phoenix predates them all :)

Those are implementations. I have no problem with that and that is 
made quite explicit in the mail I wrote. Suppose we have three 
ComponentManager interfaces, competing. Or three logging interfaces. 
Oh, wait. We do. How good. So good, in fact, that we decided to hide 
all the implementations behind *one* common interface so we could just 
forget about all of that and code as if there were only one logging
implementation. And what did we call the interface? Logger. How boringly
descriptive and uncompetitive.
 
> > We may need several
> > implementations of the event api interfaces, but I do not want
> 
> It is not always possible to have a one-size fits all interface. 
> It does not 
> make any engineering sense to restrict yourself in this way. If it is 
> possible to reuse an interface then all is good but if not then 
> that should 
> not stop you implementing your own support.

Agreed - but having several interfaces is something we "may need", 
not something we "want" just for the sake of duplicating effort.
That is so obvious that I can only assume that we are misunderstanding
each others mails.

So my -1 stands.

/LS


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message