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