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:[EMAIL PROTECTED]] > > > > On Fri, 5 Apr 2002 18:11, Leo Sutic wrote: > > > > From: Leo Simons [mailto:[EMAIL PROTECTED]] > > > > > > > > > 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:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
