I have applied for a sourceforge project, joda-primitives, to house the primitives sandbox code. Hopefully that will go OK and the move will then take place.
The sandbox code will be relicenced to the Joda Software Licence (my personal licence, which is a reworded Apache clone). Any objections please state now! Stephen ----- Original Message ----- From: "Stephen Colebourne" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Thursday, November 06, 2003 9:43 PM Subject: Re: [primitives] Object/JDK integration - was Proposed interface changes > I hereby accept the -1 veto on this topic (it is also valid according to the > rules ;-). Part of my aim with this thread was to try to draw these long > ongoing discussions to a final conclusion by clearly agreeing on design once > and for all. > > There are two clear and distinct philosophies here, and I don't think either > holds all the answers. My responses to the specific points are inline > below - they are intended for information rather than discussion. > --- > I would like to move the discussion forward into a world where there are two > primitive collection package designs (there seems to be a demand for both). > [primitives] has the name, history and rights to be the commons > implementation. (It may be a new project, but the code is old). I hope that > it can be improved with agreements on interface extensions, package changes > and additions - hopefully from the similarly designed PCJ library. I also > hope I can contribute to it. > > Therefore, the primitives sandbox code needs either: > a) a new name, remaining at commons > b) a new home, away from Apache > I'm guessing (b) is more likely, although I instinctively prefer Apache and > (a). I also hope to continue some work on this codebase, wherever it is, and > bring it to a release. > > Opinions on a/b? > > --- > Responses inline > > (1) The proposal roughly doubles the number of methods per interface while > > providing little or no additional functionality. > The additional functionality is integration. > > > (2) The proposed API is misleading. Every resulting interface and > > implementation contains many methods that declare an Object parameter but > > in actuality only accept Objects of a specific <Type>. (E.g., > > IntCollection would have add(Object) method that only accepts Integer or > > at most Number.) > Although not implemented, I wanted to have the ability to effectively plugin > a converter between primitive and Object. > > > (3) The proposed API is inconsistent: > > > > (3.a) IntList.add(Object) and IntList.add(int) are more or less equivalent > > (assuming Object instanceof Integer), but IntList.remove(Object) and > > IntList.remove(int) mean two dramatically different things. > This is actually a problem with the commons-proper version to some degree, > however the solution of two different method names is undoubtably simpler > when not extending the JDK. > > > (3.b) As proposed, methods that can be overloaded by changing the > > signatures e.g., add(Object) and add(int), will retain the same name while > > methods that require different return types must change the method name > > e.g., get(int):Object and getInt(int):int. > I toyed with the idea of always using the term 'value' when referring to > primitives, eg. addValue(), removeValue(), toValueArray(). This worked until > I thought about the confusion when a Map was implemented. The alternative > consistent approach is addInt(), removeInt(), toIntArray(). This seems an > acceptable choice too. > > > (4) At least one of the suggested advantages of the proposed > > approach--that "no wrappers or adapters are needed"--is incorrect. If > > IntList extends List, then an IntList can be used directly wherever a List > > of Integers is expected, but the converse is not true: an adapter is still > > required to support a List of Integers where an IntList is expected. > Quite correct, and such a wrapper would have a large interface to implement. > > > (5) As a result of previous point, the proposed API is asymmetric--the way > > in which we treat a List of Integers as an IntList is different from the > > way we treat an IntList as a List of Integers. > It is asymmetric, but that doesn't bother me especially. > > > (6) The proposed API is more demanding of the runtime environment. The > > current base package, being independent of java.util.*, can be used in any > > every released Java version (from 1.0.2 on), and in embedded/micro or > > sandboxed (e.g., applet) environments that do not include the java.util > > Collections API. Note that the time and space savings of the primitive > > collections API are of particular interest to these > > platforms/environments. > True, but it doesn't strike me as a major goal of the library. (J2ME writers > would IMO not be using large libraries anyway) > > > Stephen > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
