You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@leosimons.com> on 2002/04/04 14:19:40 UTC
RE: excalibur package naming (RE: [VOTE] Should Command be a sub
of event?)
> 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.
Claiming excalibur.system for a package means that an alternative to that package will have difficulty competing.
Please see http://www.mail-archive.com/avalon-dev%40jakarta.apache.org/msg07515.html
> On another, more personal note, it will make it very difficult
> for me to 'sell' Avalon internally: Having one cool codename is fine,
> but if I were to list ten or more when briefing the CTO on what
> I intend to do...
>
> ...I will be laughed out of the room.
> ...the Avalon project will get a 'geeks only' stamp on it.
:) Are there any no-geeks developing Avalon? I get the point, tho.
The questions is: where's the balance?
- Leo
__________________________________________
Launch your own web site Today!
Create a Web site for your family,
friends, photos, or a special event.
Visit: http://www.namezero.com/sitebuilder
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: excalibur package naming (RE: [VOTE] Should Command be a sub of event?)
Posted by Peter Donald <pe...@apache.org>.
On Fri, 5 Apr 2002 23:34, Berin Loritsch wrote:
> We currently have 30 Excalibur sub projects. Some of which are
> associated: bzip2, zip. Those could theorhetically be put in the
> same subproject (archive) with two jars produced out of it.
>
> Unfortunately, if we had 30 mideaval names for Excalibur, we would
> have a real mess on our hands. Leo's point, which is valid, is
> that having all mideaval names is more counter-intuitive than
> having a name more directly linked to what the package represents.
> I.e. the event based package is in a good name for it right now.
Thats fine if they are simple components. As soon as you get into
multiple-package systems that are likely to have multiple implementations
then you are in trouble.
--
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: excalibur package naming (RE: [VOTE] Should Command be a sub of event?)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@avalon.org]
>
> Abstract names are good if they are few, because our minds can
> handle that. However, I personally start losing track after about
> a dozen.
Exactly. And we can not use up all of that dozen in Excalibur.
A coder using Excalibur will have Excalibur names, plus many more
abstract names to keep track of.
Plus, that is a dozen *if you get some time to learn them*. Consider
the maintenance programmer trying to make sense of it all.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: excalibur package naming (RE: [VOTE] Should Command be a sub of event?)
Posted by Berin Loritsch <bl...@avalon.org>.
> From: Peter Donald [mailto:peter@apache.org]
>
> On Fri, 5 Apr 2002 18:11, Leo Sutic wrote:
> > > From: Leo Simons [mailto:leo@leosimons.com]
> > >
> > 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.
>
> > 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).
On this point I agree with Peter. Besides, the distribution mechanism
must be pluggable (i.e. a component that the container can use to
distribute
the selected components). And I don't know of one situation where a
"singlethreaded" component manager would really be useful. As soon as
you add a new thread (inevitable), you chance breaking the system.
> Fortress is a new and improved ECM. Under your system we
> would be forced to
> use arbitrary name decoration like the dreaded "Classic", "Modern",
> "Post-Modern" or appending version numbers. Very confusing for users.
Fortress is IMO good enough of a name.
> > 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 :)
Well, we don't want so many that they confuse users. However, a little
healthy competition is a good thing.
> > I want:
>
> You want the impossible and the impractical. Nothing is 100%
> correct for 100%
> of the situations so you can never have a perfect interface
> and competing (or
> in our case more likely cross fertilizing) products are necessary.
Be careful not to throw the baby out with the bath water.
We currently have 30 Excalibur sub projects. Some of which are
associated: bzip2, zip. Those could theorhetically be put in the
same subproject (archive) with two jars produced out of it.
Unfortunately, if we had 30 mideaval names for Excalibur, we would
have a real mess on our hands. Leo's point, which is valid, is
that having all mideaval names is more counter-intuitive than
having a name more directly linked to what the package represents.
I.e. the event based package is in a good name for it right now.
Abstract names are good if they are few, because our minds can
handle that. However, I personally start losing track after about
a dozen.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: excalibur package naming (RE: [VOTE] Should Command be a sub of
event?)
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
I agree with Leo, Proper names are great, but only ONE at the very top, Avalon. Everything else self describing.
I also agree with him that it would be a great loss because Avalon really is in the top 5%, and does not deserve to be disregarded, even if for the wrong reasons. I am a freak from way back, and even I roll my eyes at the terms, if only because someone else made them up instead of me.
Plus, they slow me down. I don't want to keep having to look everything up.
The main downfall to self describing names is the length, which bugs me too, but if it is that vs having to look up every term, I would prefer the long names.
My 2c
Leo Sutic wrote:
>
> > 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
community as opposed to company (RE: excalibur package naming)
Posted by Leo Simons <le...@apache.org>.
> > I do not know what experience you have with commercial grade
> development,
whow! Is that superiority seeping through somewhere?
Commercial grade development is classified with regards to open source
projects hosted at apache as much, much worse, unless, of course,
it is commercial grade development taking place at apache.
You try and prove otherwise.
(...)
Please. We don't really need this discussion. I can have conversations
like this all day long on slashdot, where I get to consume rude language
as an added bonus.
> > 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.
Avalon and Excalibur are in real use by real companies. Would, say, the UN
using it do it for you? It is usable in a commercial environment. Granted,
one where the decision makers understand open source and where developers
understand modern concepts like patterns, design for reuse, etc.
If you don't believe that, why are you here?
If you question whether the people that have coded most of avalon (and I
don't really mean myself) are up to the task of "commercial grade
development", then misquote the guidelines, then talk about those people
"baiting" you, well, ...
We are not a company. If we were, I'd complain about my salary. Instead,
we're a community. Please respect that.
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: excalibur package naming (RE: [VOTE] Should Command be a sub of event?)
Posted by Peter Donald <pe...@apache.org>.
On Fri, 5 Apr 2002 23:30, Leo Sutic wrote:
> > 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.
Errr ... I haven't compared it to excalibur as a whole ... I compared it to
fortress, EC and merlin - all who do much the same thing.
> 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.
hmmm.
> Yes, but the implementations in Phoenix are not supposed to be used in
> other projects.
aren't they?
> > 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.
Thats news to me. Merlin was specifically designed to work outside of phoenix
IIRC.
> > > 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?
We do.
> 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.)
ho hum.
> 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:
la ti di da.
> 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...
I can see that you are a true professional and we need to emulate you much
more.
> 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.
Simple problems have simple answers. However Even logging has at least 5-6
different interfaces. I still haven't heard you come up with a one interface
fits all probalems yet...
> > > 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.
And is worthless under apache rules ;)
--
Cheers,
Pete
---------------------------------------------------
"Marriage, Friends, Religon -- these are the demons
you must slay in order to suceed in business.."
-- Mr. Burns, The Simpsons
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: excalibur package naming (RE: [VOTE] Should Command be a sub
of event?)
Posted by Paul Hammant <Pa...@yahoo.com>.
Jeff,
>>Guys, this HAS to be the funniest serious thread I have
>>read in a long while... I really thought it was an April
>>Fool's joke when I read the first post, but the fact that
>>this is a proposal in earnest makes the exchange even
>>funnier.
>>
>
>I say we extend the medieval naming thing to committers, and insist on
>full honorifics at the top of each email. As Leo is so wonderfully
>entertaining when pushed, he can be the Court Jester.
>
No, Colors are better............
- Mr Black
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: excalibur package naming (RE: [VOTE] Should Command be a sub of event?)
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> I say we extend the medieval naming thing to committers, and insist on
> full honorifics at the top of each email. As Leo is so wonderfully
> entertaining when pushed, he can be the Court Jester.
Hhmmm... Sir Gonzo! Yeah! I LIKE THAT!
> -- Sir Geoffrey, Master of Dependencies
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: excalibur package naming (RE: [VOTE] Should Command be a sub of event?)
Posted by Jeff Turner <je...@socialchange.net.au>.
On Fri, Apr 05, 2002 at 09:50:02AM -0400, Gonzalo A. Diethelm wrote:
> > + 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 ())
>
> [snip]
>
> Guys, this HAS to be the funniest serious thread I have
> read in a long while... I really thought it was an April
> Fool's joke when I read the first post, but the fact that
> this is a proposal in earnest makes the exchange even
> funnier.
I say we extend the medieval naming thing to committers, and insist on
full honorifics at the top of each email. As Leo is so wonderfully
entertaining when pushed, he can be the Court Jester.
-- Sir Geoffrey, Master of Dependencies
(ducking, running, profusely apologising to Leo whom he agrees with.. ;)
> To add some content to my message: I'm not a committer in
> Avalon, but I am in Turbine. So, FWIW, I'll second Leo with
> a, let's say, symbolic -1.
>
> Best regards,
>
>
> --
> Gonzalo A. Diethelm
> gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: excalibur package naming (RE: [VOTE] Should Command be a sub of event?)
Posted by Peter Royal <pr...@managingpartners.com>.
On Friday 05 April 2002 02:43 pm, Leo Simons wrote:
> 6): java does not allow duplication in descriptive names among peers.
> 7): we want our projects to be flat, ie using a structure like
> org.apache.${projectname}.${packagename}.
> 8): 6) + 7) -> purely descriptive names are not always an option. We will
> use nondescriptive names instead in those cases.
(my ad&d and king arthur knowledge is shabby at best).
IMHO, descriptive names are best for classes. In case 8, how about a
comprimise such as the ExcaliburComponentManager. Its a unique name but
identifies a component manager from Excalibur. In the same token you could
have a DaggerComponentManager, BroadswordComponentManager, etc, etc. But just
having a class called Dagger, doesn't do me much good unless you stare at it
all day.
For those of us that are more users of Avalon rather than users + developers,
I find that I don't have to deal with the "internal"-ish classes very much
component mgr + friends. I have that infrastructure set up and thanks to the
beauty and elegance of the framework I just spend my time with the lifestyle
interfaces and my components. It is very nice to have descriptive class and
interface names when I do go back to look at the underlying avalon code,
though.
Anyways that's kind of rambly, but please don't name classes/interfaces
solely after non-related things. At least prefix.
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: excalibur package naming (RE: [VOTE] Should Command be a sub
of event?)
Posted by Paul Hammant <Pa...@yahoo.com>.
Pete,
I agree.
Leo - I completely agree that we should not be inventing medieval
sub-project/package names, but please let it slide. Why? This list is
not as adversarial as many other at jakarta, and I really like that. I
learned years ago, that one does not have to always get one's way....
Let it go dude.
- Paul
>I hope neither of you feels you have to be right on this one.
>
>It is, after all only software. Not like it is going to cause anyone's kid to be hit by a car or something, either way.
>
>Leo Sutic wrote:
>
>>>From: Leo Simons [mailto:leosimons@apache.org]
>>>
>>>Of course, we are all wrong. Let us listen to my old rpg character and
>>>learn where it went wrong.
>>>
>>>1): we have interfaces. These define components that are used to satisfy
>>> some use cases.
>>>2): we have widely applicable components.
>>>3): 1) + 2) -> we potentially have multiple component interfaces that
>>> satisfy the same use case.
>>>4): we have multiple implementations of 1).
>>>5): 3) + 4) -> purely descriptive naming of 1) and 2) will lead to
>>> some duplication in descriptive names.
>>>6): java does not allow duplication in descriptive names among peers.
>>>
>>Yes, but can they not be disambiguated any other way than by
>>giving them fantasy names? Could you *please* re-read the reply
>>I sent to your first mail
>>(http://archive.covalent.net/jakarta/avalon-dev/2002/04/0228.xml) which
>>prompted Peter Donald's reply and my last letter before this one?
>>
>>As an example from the Java API: class Reference exists
>>in both java.lang.ref.Reference and javax.naming.Reference.
>>No problem - different packages.
>>
>>>7): we want our projects to be flat, ie using a structure like
>>> org.apache.${projectname}.${packagename}.
>>>8): 6) + 7) -> purely descriptive names are not always an option. We will
>>> use nondescriptive names instead in those cases.
>>>
>>Do we want to use the flat structure you propose if the cost
>>is incomprehensible names? I do not.
>>
>>>That other Leo is 'shouting' a lot because he does not like the
>>>conclusion reached. He does not point out the flaw in logic, or
>>>an alternative logical approach that satisfies our requirments.
>>>
>>I suppose questions of usability does not factor in
>>(http://archive.covalent.net/jakarta/avalon-dev/2002/04/0178.xml)
>>
>>I suppose (http://archive.covalent.net/jakarta/avalon-dev/2002/04/0228.xml)
>>does not count for an answer or a suggestion, as you have not replied to
>>it and do not consider it a "logical approach". But could you
>>please point out why it does not solve the problems?
>>
>>>It is clear that the current conclusion works for quite a few of the
>>>committers.
>>>
>>Maybe, but looking at the list lately I have seen at least some people
>>who do agree with me. So even if it does work for "quite a few" as you say
>>it does *not* work for quite a few others. I also note that those for whom
>>it does not work are not committers of Avalon, but users of it, which
>>means that my assumption that only someone who spends a lot of time
>>with Avalon can pack these proposed arcane names into their head. Of
>>what use will Excalibur be if only committers can use it?
>>
>>Furthermore I do not agree that "the current conclusion works for quite a
>>few of the committers" is reason enough to ignore the whole Jakarta voting
>>process. I have thrown my veto against the change. By the rules the only
>>way you can change that is by lobbying me and trying to convince me that
>>I am wrong. If your statement was meant as a joke then I fell for it,
>>but if it isn't you should reconsider.
>>
>>>(Frankly, I don't care that much what *your* manager thinks
>>>of open source projects, or roleplaying. I need stuff to work. It is not
>>>a problem for me.)
>>>
>>I'd say that attitude is wrong for several reasons, but I can not change
>>it. All I can say is that the attitude of my manager and myself in regards
>>to this is more common than you'd think among professional developers.
>>
>>If you are not willing to accept that on my saying so, and can not
>>consult a chief architect or CTO, the proof is in the Java API itself.
>>You find only descriptive names. There may be some very few exceptions
>>(swing), but as a rule, names are descriptive. There is a reason for
>>that, and it is not lack of fantasy.
>>
>>>Since the other Leo has not yet formulated a logical process leading
>>>to a different conclusion, I'd like to give him oppurtunity to do so.
>>>
>>I believe I have several times stated that the approach you advocate
>>will make Excalibur unusable for commercial development. I have suggested
>>alternatives. I'd like to repreat those arguments here, but it would
>>appear that you are only baiting me - no matter what I reply you will deny
>>that it is a logical process.
>>
>>Just one final thought for you: How often is a serious proposal on this
>>list mistaken for an April Fool's joke? *Four* *days* after April 1st?
>>
>>-1 stands.
>>
>>/LS
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: excalibur package naming (RE: [VOTE] Should Command be a sub of
event?)
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
I hope neither of you feels you have to be right on this one.
It is, after all only software. Not like it is going to cause anyone's kid to be hit by a car or something, either way.
Leo Sutic wrote:
>
> > From: Leo Simons [mailto:leosimons@apache.org]
> >
> > Of course, we are all wrong. Let us listen to my old rpg character and
> > learn where it went wrong.
> >
> > 1): we have interfaces. These define components that are used to satisfy
> > some use cases.
> > 2): we have widely applicable components.
> > 3): 1) + 2) -> we potentially have multiple component interfaces that
> > satisfy the same use case.
> > 4): we have multiple implementations of 1).
> > 5): 3) + 4) -> purely descriptive naming of 1) and 2) will lead to
> > some duplication in descriptive names.
> > 6): java does not allow duplication in descriptive names among peers.
>
> Yes, but can they not be disambiguated any other way than by
> giving them fantasy names? Could you *please* re-read the reply
> I sent to your first mail
> (http://archive.covalent.net/jakarta/avalon-dev/2002/04/0228.xml) which
> prompted Peter Donald's reply and my last letter before this one?
>
> As an example from the Java API: class Reference exists
> in both java.lang.ref.Reference and javax.naming.Reference.
> No problem - different packages.
>
> > 7): we want our projects to be flat, ie using a structure like
> > org.apache.${projectname}.${packagename}.
> > 8): 6) + 7) -> purely descriptive names are not always an option. We will
> > use nondescriptive names instead in those cases.
>
> Do we want to use the flat structure you propose if the cost
> is incomprehensible names? I do not.
>
> > That other Leo is 'shouting' a lot because he does not like the
> > conclusion reached. He does not point out the flaw in logic, or
> > an alternative logical approach that satisfies our requirments.
>
> I suppose questions of usability does not factor in
> (http://archive.covalent.net/jakarta/avalon-dev/2002/04/0178.xml)
>
> I suppose (http://archive.covalent.net/jakarta/avalon-dev/2002/04/0228.xml)
> does not count for an answer or a suggestion, as you have not replied to
> it and do not consider it a "logical approach". But could you
> please point out why it does not solve the problems?
>
> > It is clear that the current conclusion works for quite a few of the
> > committers.
>
> Maybe, but looking at the list lately I have seen at least some people
> who do agree with me. So even if it does work for "quite a few" as you say
> it does *not* work for quite a few others. I also note that those for whom
> it does not work are not committers of Avalon, but users of it, which
> means that my assumption that only someone who spends a lot of time
> with Avalon can pack these proposed arcane names into their head. Of
> what use will Excalibur be if only committers can use it?
>
> Furthermore I do not agree that "the current conclusion works for quite a
> few of the committers" is reason enough to ignore the whole Jakarta voting
> process. I have thrown my veto against the change. By the rules the only
> way you can change that is by lobbying me and trying to convince me that
> I am wrong. If your statement was meant as a joke then I fell for it,
> but if it isn't you should reconsider.
>
> > (Frankly, I don't care that much what *your* manager thinks
> > of open source projects, or roleplaying. I need stuff to work. It is not
> > a problem for me.)
>
> I'd say that attitude is wrong for several reasons, but I can not change
> it. All I can say is that the attitude of my manager and myself in regards
> to this is more common than you'd think among professional developers.
>
> If you are not willing to accept that on my saying so, and can not
> consult a chief architect or CTO, the proof is in the Java API itself.
> You find only descriptive names. There may be some very few exceptions
> (swing), but as a rule, names are descriptive. There is a reason for
> that, and it is not lack of fantasy.
>
> > Since the other Leo has not yet formulated a logical process leading
> > to a different conclusion, I'd like to give him oppurtunity to do so.
>
> I believe I have several times stated that the approach you advocate
> will make Excalibur unusable for commercial development. I have suggested
> alternatives. I'd like to repreat those arguments here, but it would
> appear that you are only baiting me - no matter what I reply you will deny
> that it is a logical process.
>
> Just one final thought for you: How often is a serious proposal on this
> list mistaken for an April Fool's joke? *Four* *days* after April 1st?
>
> -1 stands.
>
> /LS
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: excalibur package naming (RE: [VOTE] Should Command be a sub of event?)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> Of course, we are all wrong. Let us listen to my old rpg character and
> learn where it went wrong.
>
> 1): we have interfaces. These define components that are used to satisfy
> some use cases.
> 2): we have widely applicable components.
> 3): 1) + 2) -> we potentially have multiple component interfaces that
> satisfy the same use case.
> 4): we have multiple implementations of 1).
> 5): 3) + 4) -> purely descriptive naming of 1) and 2) will lead to
> some duplication in descriptive names.
> 6): java does not allow duplication in descriptive names among peers.
Yes, but can they not be disambiguated any other way than by
giving them fantasy names? Could you *please* re-read the reply
I sent to your first mail
(http://archive.covalent.net/jakarta/avalon-dev/2002/04/0228.xml) which
prompted Peter Donald's reply and my last letter before this one?
As an example from the Java API: class Reference exists
in both java.lang.ref.Reference and javax.naming.Reference.
No problem - different packages.
> 7): we want our projects to be flat, ie using a structure like
> org.apache.${projectname}.${packagename}.
> 8): 6) + 7) -> purely descriptive names are not always an option. We will
> use nondescriptive names instead in those cases.
Do we want to use the flat structure you propose if the cost
is incomprehensible names? I do not.
> That other Leo is 'shouting' a lot because he does not like the
> conclusion reached. He does not point out the flaw in logic, or
> an alternative logical approach that satisfies our requirments.
I suppose questions of usability does not factor in
(http://archive.covalent.net/jakarta/avalon-dev/2002/04/0178.xml)
I suppose (http://archive.covalent.net/jakarta/avalon-dev/2002/04/0228.xml)
does not count for an answer or a suggestion, as you have not replied to
it and do not consider it a "logical approach". But could you
please point out why it does not solve the problems?
> It is clear that the current conclusion works for quite a few of the
> committers.
Maybe, but looking at the list lately I have seen at least some people
who do agree with me. So even if it does work for "quite a few" as you say
it does *not* work for quite a few others. I also note that those for whom
it does not work are not committers of Avalon, but users of it, which
means that my assumption that only someone who spends a lot of time
with Avalon can pack these proposed arcane names into their head. Of
what use will Excalibur be if only committers can use it?
Furthermore I do not agree that "the current conclusion works for quite a
few of the committers" is reason enough to ignore the whole Jakarta voting
process. I have thrown my veto against the change. By the rules the only
way you can change that is by lobbying me and trying to convince me that
I am wrong. If your statement was meant as a joke then I fell for it,
but if it isn't you should reconsider.
> (Frankly, I don't care that much what *your* manager thinks
> of open source projects, or roleplaying. I need stuff to work. It is not
> a problem for me.)
I'd say that attitude is wrong for several reasons, but I can not change
it. All I can say is that the attitude of my manager and myself in regards
to this is more common than you'd think among professional developers.
If you are not willing to accept that on my saying so, and can not
consult a chief architect or CTO, the proof is in the Java API itself.
You find only descriptive names. There may be some very few exceptions
(swing), but as a rule, names are descriptive. There is a reason for
that, and it is not lack of fantasy.
> Since the other Leo has not yet formulated a logical process leading
> to a different conclusion, I'd like to give him oppurtunity to do so.
I believe I have several times stated that the approach you advocate
will make Excalibur unusable for commercial development. I have suggested
alternatives. I'd like to repreat those arguments here, but it would
appear that you are only baiting me - no matter what I reply you will deny
that it is a logical process.
Just one final thought for you: How often is a serious proposal on this
list mistaken for an April Fool's joke? *Four* *days* after April 1st?
-1 stands.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: excalibur package naming (RE: [VOTE] Should Command be a sub of event?)
Posted by Leo Simons <le...@apache.org>.
<IC>
The venerable dr. Columbo looks at the vocal fight taking place in front
of him, smiling with a look from which you might be able to tell he has
seen it all before, and gotten rather tired of the shouting youngsters.
Deciding that he should end the dispute before matters lead from bad to
blood, he rises from his chair, flattens his beard, then steps into the
midst of the argument. "Now, friends, if I may have a word?"
</IC>
seriously, offend AD&D anymore and I'll bury you guys in it =)
Of course, we are all wrong. Let us listen to my old rpg character and
learn where it went wrong.
1): we have interfaces. These define components that are used to satisfy
some use cases.
2): we have widely applicable components.
3): 1) + 2) -> we potentially have multiple component interfaces that
satisfy the same use case.
4): we have multiple implementations of 1).
5): 3) + 4) -> purely descriptive naming of 1) and 2) will lead to
some duplication in descriptive names.
6): java does not allow duplication in descriptive names among peers.
7): we want our projects to be flat, ie using a structure like
org.apache.${projectname}.${packagename}.
8): 6) + 7) -> purely descriptive names are not always an option. We will
use nondescriptive names instead in those cases.
That other Leo is 'shouting' a lot because he does not like the
conclusion reached. He does not point out the flaw in logic, or
an alternative logical approach that satisfies our requirments.
this leads to Pete uttering, sputtering, saying typical Ozzie stuff
like *bzzt*.
Now that we have a problem diagnosis, we can start thinking about a
treatment, and moreover, who should administer the treatment. It is
clear that the current conclusion works for quite a few of the
committers. (Frankly, I don't care that much what *your* manager thinks
of open source projects, or roleplaying. I need stuff to work. It is not
a problem for me.)
Since the other Leo has not yet formulated a logical process leading
to a different conclusion, I'd like to give him oppurtunity to do so.
If he is unable to, I think his -1 is unwarranted.
<IC>
"And that, my friends, is how it shall be. Please take time to ponder
these statements, and refute them in time should you be so enabled."
With those words, the Doctor leaves the utterly flabbergasted patrons
to their thoughts, returning to the bar.
With a slight twinkle in his eyes, he orders a coffee.
</IC>
cheers, all,
- Leo Simons (LSD, not /LS :)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: excalibur package naming (RE: [VOTE] Should Command be a sub of event?)
Posted by Peter Donald <pe...@apache.org>.
On Fri, 5 Apr 2002 23:42, Berin Loritsch wrote:
> Noone on this list has ever suggested we carry this down to the
> class/names
> and methods.
>
> Be careful with your analogies Leo, or Peter will ignore them
> completely.
In process ;)
> Make sure you are comparing apples with apples and not with oranges.
But that would not fit in with his style (ie "straw men")
--
Cheers,
Pete
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: excalibur package naming (RE: [VOTE] Should Command be a sub of event?)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@avalon.org]
>
> Noone on this list has ever suggested we carry this down to the
> class/names and methods.
>
> Be careful with your analogies Leo, or Peter will ignore them
> completely. Make sure you are comparing apples with apples and not with
oranges.
>
> We are talking sub-project names not class names.
Yes, but since the sub project names show up as package names, ***as
a potential user of Excalibur has to keep track of them***, they are
just as bad.
> Inside of Fortress, there are regular class names that represent what
> the classes do. I am not going to change that.
No, and I never thought you would - that would be too confusing, wouldn't
it? But you are a committer, and furthermore you wrote that code.
For someone who isn't a committer, and who has no experience with the code,
having strange package names is as confusing as renaming classes/methods
would be for you.
Like I said, if these names were never ever shown to anyone except those
actually developing Avalon, then I could maybe grudgingly accept the
proposed convention. But they are not. Users, who get some stuff from
Excalibur, some from Cocoon, some from Xerces, etc. etc. will be
exposed to them.
And that will confuse them something terrible, for no good reason.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: excalibur package naming (RE: [VOTE] Should Command be a sub of event?)
Posted by Berin Loritsch <bl...@avalon.org>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> 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)
Noone on this list has ever suggested we carry this down to the
class/names
and methods.
Be careful with your analogies Leo, or Peter will ignore them
completely.
Make sure you are comparing apples with apples and not with oranges.
We are talking sub-project names not class names.
Inside of Fortress, there are regular class names that represent what
the
classes do. I am not going to change that.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: excalibur package naming (RE: [VOTE] Should Command be a sub of event?)
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> + 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 ())
[snip]
Guys, this HAS to be the funniest serious thread I have
read in a long while... I really thought it was an April
Fool's joke when I read the first post, but the fact that
this is a proposal in earnest makes the exchange even
funnier.
To add some content to my message: I'm not a committer in
Avalon, but I am in Turbine. So, FWIW, I'll second Leo with
a, let's say, symbolic -1.
Best regards,
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: excalibur package naming (RE: [VOTE] Should Command be a sub of event?)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: excalibur package naming (RE: [VOTE] Should Command be a sub of event?)
Posted by Peter Donald <pe...@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.
> 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).
Fortress is a new and improved ECM. Under your system we would be forced to
use arbitrary name decoration like the dreaded "Classic", "Modern",
"Post-Modern" or appending version numbers. Very confusing for users.
And there is no single feature that separates any one out.
* ECM/Fortress integrate Pooling.
* Phoenix hosts multiple applications
* Merlin/Phoenix have stronger meta-data support (ie need to declare
dependencies and supported services)
etc.
I would love to see you come up with a name for each of them that is
representative and would be clear to users.
> 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.
They don't represent what
> 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 :)
> 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.
> I want:
You want the impossible and the impractical. Nothing is 100% correct for 100%
of the situations so you can never have a perfect interface and competing (or
in our case more likely cross fertilizing) products are necessary.
--
Cheers,
Pete
---------------------------------------------------
"Marriage, Friends, Religon -- these are the demons
you must slay in order to suceed in business.."
-- Mr. Burns, The Simpsons
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: excalibur package naming (RE: [VOTE] Should Command be a sub of event?)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> 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.
But suppose we have several CM implementations. They obviously differ
in some ways - one may be threadsafe, one may work over a network
or whatever. Now suppose someone is looking for a CM implementation
that has the following properties:
+ Must be ThreadSafe
+ Must have a SOAP interface
and is faced with this list:
ExcaliburComponentManager
AvalonComponentManager
KingArthurComponentManager
As opposed to:
SingleThreadedComponentManager
NetworkComponentManager
SOAPComponentManager
What is easier?
The manages probably have some associated classes, so to avoid name
collisions we'd put them in separate subpackages. Pick one version:
org.apache.avalon.excalibur.castle.glacis.ExcaliburComponentManager
org.apache.avalon.excalibur.castle.curtainwall.AvalonComponentManager
org.apache.avalon.excalibur.castle.myth.KingArthurComponentManager
or:
org.apache.avalon.excalibur.component.singlethreaded.SingleThreadedComponent
Manager
org.apache.avalon.excalibur.component.net.NetworkComponentManager
org.apache.avalon.excalibur.component.soap.SOAPComponentManager
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.
> Claiming excalibur.system for a package means that an alternative
> to that package will have difficulty competing.
We do not want several competing event packages. We may need several
implementations of the event api interfaces, but I do not want
interface excalibur.suticsevent.EventManager
interface excalibur.simonsevent.EventManager
with those being incompatible. That road ends with:
excalibur.log4e.Logger
excalibur.logtool.Logger
excalibur.logger.Logger
with log4e claiming to be most used, logtool claiming better
architecture and logger being the one un-agreed upon "standard".
Any similarities between the above and real projects are imaginary.
I want:
interface excalibur.event.EventManager { ... }
class excalibur.event.sutic.EventManagerImpl implements EventManager {
... }
class excalibur.event.simon.EventManagerImpl implements EventManager {
... }
As for the subpackage names, they should be descriptive of the difference
between the two implementations:
class excalibur.event.singlethreaded.EventManagerImpl
implements EventManager { ... }
class excalibur.event.threadsafe.EventManagerImpl
implements EventManager { ... }
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>