Ok, so I went back to write my little proposal (which I'm not even going to mention now). In order to make sure my proposal was well informed and thus a higher chance of being adopted, I went back to take a look at previous discussions about commons-core, dependencies between commons components, and other related topics. While very depressing[*], this exercise was very informative, and is keeping me from making an ill-advised proposal.

Even with the release of a commons-core or a commons-combo or whatever, the issue of interdependencies isn't going to go away. Classes and functionality need to be put into the most appropriate classes, and only when said functionality is absolutely necessary.

My current thoughts are that maybe this ClassMap shouldn't even be there. While it does provide some interesting functionality that I know would be useful for the conversion stuff (as was the original example that Hen described), the semantics of the super interface/class is way under defined. And even just adding documentation isn't going to solve that, as different people may want different semantics. I'm beginning to think that if someone wants such a functionality they could have their project depend on both lang and collections and implement the semantics they want on their own. In other words, I think that ClassMap might be a little bit outside the scope of the collections component, even if it *is* a map.

btw, an eventual dependency on lang and/or pattern might be acceptable, but as Rodney pointed out, ClassMap isn't the best justification for doing that at this point.

regards,
michael

[*] If you're curious, search archives in June for messages with the subject of "architecture", and messages in August with subject of "cross dependecy"[sic] and "pattern charter" (case insensitive). That was right before the start of the nearly two-week long debate on public constructors. Fun, fun, fun.

Michael A. Smith wrote:
Agreed. Care must be taken when adding dependencies, especially to collections and lang. I have an alternative suggestion, but want to write it up as a more formal proposal. Hopefully I'll get that done by the end of the weekend.
regards,
michael

On Fri, 25 Oct 2002, Waldhoff, Rodney wrote:

Personally, I'd prefer not to have collections depend upon lang
(currently it doesn't depend upon anything else, correct?), at least
not if ClassMap is the best justification we have for it.

A lot of other packages use Collections, so adding a new dependency to
Collections is adding a new dependency to a lot of modules.  We should
be very careful and deliberate about that.


Much of the code for getting all the superclasses and superinterfaces of a class is coded in the upcoming [lang] reflection code. Maybe the next collections release should depend on [lang]?

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



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

--
Michael A. Smith
[EMAIL PROTECTED]



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

Reply via email to