Simons,
this whole naming issue started because of this problem:
When you have two subprojects that both are best described by
the same name - for example, "event", they would, given our
agreed-upon naming convention, end up in the same package:
excalibur.event
This is bad, because it just invites namespace collisions:
for example, both subprojects are likely to have a class
or interface named Event.
The solution proposed for this is to replace the descriptive
name (in this case "event") with an abstract name. Since there
are potentially more abstract names than descriptive names that
can fit a subproject, there is little to no risk of naming
collisions.
Is this your understanding of the problem, proposed solution
and motivation behind it as well? (Just checking.)
> From: Leo Simons [mailto:[EMAIL PROTECTED]]
>
> > As an example from the Java API: class Reference exists
> > in both java.lang.ref.Reference and javax.naming.Reference.
> > No problem - different packages.
>
> As was said before: we're talking 'bout package names, not class
> names. The fact that java has indeed namespace support (through
> packages) is well known but doesn't say anything about packages.
As you can disambiguate class names you can disambiguate subpackage
names. If I implement an ObjectStore I would maybe put it in a
package named objectstore. If I knew that there would be several
implementations I would probably put it in objectstore.<?> for example,
objectstore.filesystem.
> > Do we want to use the flat structure you propose if the cost
> > is incomprehensible names? I do not.
>
> That structure has been proposed several times, and accepted. I
> am open to changing it again if there if enough reason to do so.
> I don't think the cost of the flat structure is incomprehensible names.
Not neccesarily, but the fact that you *do* get namespace collisions
that you must solve by using non-descriptive names indicates
that a flat structure does not scale too well.
> Quoting the Java API once more, it contains many packages in
> java.* and javax.* (certainly more than excalibur), with peer
> package dependencies.
And whenever there is multiple implementations of one interface
that is solved by putting the implementations in subpackages:
javax.swing.plaf.*
> Leo Sutic:
> > We do not want several competing event packages.
> > We may need several implementations of the event api
> > interfaces, but I do not want
>
> > interface excalibur.suticsevent.EventManager
> > interface excalibur.simonsevent.EventManager
>
> > with those being incompatible.
>
> Basically, in the 'logic rule world', you are saying: "I don't
> want #4". That is no solution, as we have #4 and can't really do
> without it (or really want to, at least not completely).
The logical steps, quoted:
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.
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.
No. I'm not arguing against #4. That would be madness. I'm saying
"We do not want #3." I tried to indicate that by defining two
*interfaces*, but I apologize if I was unclear.
In my experience, having several interfaces to
the same functionality always leads to one abstracting away from
the multiple interfaces and putting it behind a single interface
(like we did with Logger). Or when the functionality of two
interfaces partially overlap, refactor.
I *am* saying that the implementations in #4 should be named in a
certain way to solve the original problem described at the top
of this letter.
> Leo Sutic
> > As for the subpackage names, they should be
> > descriptive of the difference between the two
> >implementations:
> <example snipped>
>
> I agree. This is however also not always possible, as there may
> well be multiple differences, differences that cannot be keyed in
> a single word (or even phrase), etc etc.
But I say that those instances are very rare. So rare that they
can be dealt with individually, much as one would deal with exceptions
to coding standards.
> You misintepreted/I miswrote my statement. (...) Let's drop this :)
Dropped.
> > 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.
>
> err...all rules are open to interpretation. If I say "we cannot
> just have descriptive names as that does not work" you can try to -1.
>
> the guidelines say "All vetos must contain an explanation of why
> the veto is appropriate. Vetos with no explanation are void."
> They also say "Long term plans are simply announcements that
> group members are working on particular issues related to the
> Project. These are not voted on,"
You would be on shaky ground saying that I have not given an explanation,
so that is no argument.
You are, however, correct in saying that I can not veto the plan,
for the very simple reason that there is no vote.
The -1 in this context is more of a promise to veto any code
changes, including additions, that may come as a result of actually
*executing* the plan, and any attempt to have the proposal accepted
as an Avalon guideline. Both of those are product changes.
So I still believe that my -1 has some basis in the voting rules.
> Let me rephrase: I don't care very much about what your manager
> thinks. He might be incompetent and blatantly stupid (so, I'm
> prejudiced...).
Let me try to explain why you should:
Avalon is, as you say, used by many companies and used in mission-critical
products. This is good for the developers of those projects (get stuff
done better and faster) and good for Avalon (some actually contribute
something back).
Of those participating on avalon-dev, many are paid professionals whose
companies use Avalon. For cocoon-dev it is even more common than here,
and axis-dev have full-time IBM and Macromedia people who are paid
to develop.
The more developers that come to Avalon, the better. Not
because more is better, but the more people that do get here, the higher
the probability that one of them will make a contribution.
Without developers, Avalon will not grow.
The decision regarding what framework to use is ultimately up to the CTO.
He may not be the one actually proposing what framework to use, but he can
always overrule anyone's proposal with his veto.
So, if we in Avalon alienate CTOs, we lose developers. Those projects
will use some other framework, and Avalon will suffer for it. It does
not matter that the other framework is inferior - people will use it
anyway because they are ordered to do so. Avalon will be more and more
marginalized and develop less and less as the previously inferior
framework gets more and more features, as faults in it is fixed,
as it builds momentum.
So why should you care about all the idiot CTOs in the world?
Because idiot as they may be, they do make the decisions that
affect this project. Not directly, but their decisions have
quite longer lasting effects.
> :) I'm CTO myself...but seriously, where is there proof in the
> Java API that I should care what your manager thinks of open
> source projects or roleplaying?
There is no such proof as I can not prove that you should
care about anything.
But as someone who has been in contact with CTOs, I promise you that
one thing that definitely will turn them away from Avalon is if they
do not see it as professional enough. Having medieval names does not
look good. (Besides other faults.)
I would hate us being discarded for reasons of not looking good
enough when Avalon is so good.
The proof you may find in the Java API is that abstract names
are the very rare exceptions in API's intended for enterprise
development. This is for a reason. A CTO has to decide whether
a framework, or API, or product is worth committing to. To be able
to do that and have time for other tasks, most CTOs (and people)
have a crap filter - if you just by glancing at something think
it sucks, it probably does.
If we do not watch out, a CTO looking at Avalon with several
medieval names risk having his crap filter triggered. On the other
hand, if we immediately present the CTO with something that just
screams "ENTERPRISE DEVELOPMENT", because it *looks* like other frameworks
for enterprise development, he will get that warm, fuzzy feeling
and *bam* then we can lay it on with just how technically
superior we are. Because now he will *stay* and *listen*.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
