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:[EMAIL PROTECTED]] >>> >>>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:[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]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
