avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: excalibur package naming (RE: [VOTE] Should Command be a sub of event?)
Date Sat, 06 Apr 2002 08:10:00 GMT
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:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
>>For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
>>
>
>--
>To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
>
>
>




--
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