RE: excalibur.fortress

[Berin Loritsch <bl...@apache.org>]

Leo, the mail has been weird lately.  I don't recall seeing the
email raising objections.

> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com] 
> 
> Berin,
> 
> I noticed that you have moved the ContainerManager etc. to 
> excalibur.fortress. If you have already discarded the reasons
> I listed against making this change, then, fine. But I'd like 
> to hear your response to them.
> 
> If not, please re-evaluate this change. I have included a copy 
> of the relevant parts of my previous mail below.
> 
> /LS
> 
> ---------------------------------------------
> 
> If people were bewildered by the size of Excalibur before it 
> was split up, just consider a newbie surfing in on the Avalon 
> site and having to pick a subproject between:
> 
>   joust
>   robberbaron
>   fairmaiden
> 
> There is just no way that a newbie will be able to keep eveything 
> in their head:
> 
>   "OK, so the Events in 'joust' go to the EventHandler that uses
>    the ComponentManager from... uh... <look in docs> 'fortress'..."

I didn't make the change for Event.


> Repeat the above for the poor maintenance programmer. K3w1 names 
> are fine for entire projects where a descriptive name is either 
> unmanageable or ends up being not really descriptive due to the scope:
> 
>       Excalibur -> LotsOfComponentsForAvalonFramework
> 
> But please do not extend this too far down the project 
> hierarchy. It makes the source code incomprehensible.
> 
> 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...


Ok, but how about for pivotal or large integration components
like Fortress (aka system)?  That integrates a bunch of other
excalibur components.  I am not that comfortable moving event
to something else, because it is sufficiently descriptive.

For fortress, I think that the name is descriptive enough that
you get the impact  of what is in there.

Your points are well taken though.

BTW, I can't use Container because that was already taken by an
older package.


>   ...I will be laughed out of the room.
>   ...the Avalon project will get a 'geeks only' stamp on it.

;P


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: excalibur.fortress

[Leo Sutic <le...@inspireinfrastructure.com>]

> From: Berin Loritsch [mailto:bloritsch@apache.org]
> 
> Leo, the mail has been weird lately.  I don't recall seeing the
> email raising objections.

Berin,

seems like much of Apache is having a bad day - cvs.apache.org 
gives me errors when I log in. The email did contain a -1 from me,
and this is viewable at the archives.
 
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com] 
> > 
> > If people were bewildered by the size of Excalibur before it 
> > was split up, just consider a newbie surfing in on the Avalon 
> > site and having to pick a subproject between:
> > 
> >   joust
> >   robberbaron
> >   fairmaiden
> > 
> > There is just no way that a newbie will be able to keep eveything 
> > in their head:
> > 
> >   "OK, so the Events in 'joust' go to the EventHandler that uses
> >    the ComponentManager from... uh... <look in docs> 'fortress'..."
> 
> I didn't make the change for Event.

True, I wanted to illustrate the consequences. 
 
> > Repeat the above for the poor maintenance programmer. K3w1 names 
> > are fine for entire projects where a descriptive name is either 
> > unmanageable or ends up being not really descriptive due to the scope:
> > 
> >       Excalibur -> LotsOfComponentsForAvalonFramework
> > 
> > But please do not extend this too far down the project 
> > hierarchy. It makes the source code incomprehensible.
> > 
> > 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...
> 
> 
> Ok, but how about for pivotal or large integration components
> like Fortress (aka system)?  That integrates a bunch of other
> excalibur components.

I think it is even more important to have descriptive names
for pivotal and large integration components. 

>  I am not that comfortable moving event
> to something else, because it is sufficiently descriptive.

Fortress = a security package? RSA? 3DES? Encrypted storage?

> For fortress, I think that the name is descriptive enough that
> you get the impact  of what is in there.
> 
> Your points are well taken though.
> 
> BTW, I can't use Container because that was already taken by an
> older package.

containermanager is still available, and would be even better. Why not?
The package does contain an interface named ContainerManager and
an implementation of it. If the ContainerManager interface had been
named Fortress instead, and if "fortress" was a generally accepted
engineering term for what we now call a ContainerManager, I would have
been +1000 for renaming it to fortress. But it isn't and I'm not.

Consider - why do we name classes with as descriptive names as
possible, and why should that not apply to packages? In the basic
java api, there is one package that does not have a descriptive
name: swing. But then, its sub packages do.

If these package names were only ever used and referred to within
the project itself, I could accept some more poetic names,
but as these names will be used by people with

 a) limited grasp of English
 b) no grasp of medieval terminology
 c) a lot of other packages in their code base

When someone like that thinks "right, I need something that does X."
the person must somehow figure out what package to look in, and maybe
what class to use. Having descriptive names help, not having them
is an obstacle. Just test yourself: what would be in a package named
broadsword? Do you think you and I and everyone else on the list
will come up with the same answer, or even similar answers?

It is not enough to come up with a name that sort-a-kind-a-fits the
content when you know exactly what's in there, but also something that
causes you to associate to the package name when you are looking for
something *like* the contents and have never seen the actual contents 
before.

Telling people the difference between avalon.framework, avalon.excalibur,
and other packages so they know where to look for the stuff they need is 
bad enough for me  right now. Adding more non-descriptive names is a 
nightmare waiting to happen.

> >   ...I will be laughed out of the room.
> >   ...the Avalon project will get a 'geeks only' stamp on it.
> 
> ;P

Yes, that would be a concise description of the reaction I'd get.

/LS

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>