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 20:47:54 GMT

> 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 

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.


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

View raw message