Unfortunately, previous attempts to get me a signin at codehaus failed, probably due to my ineptitude at command lines. I know the sourceforge way, so it'll do for the moment. If you or anyone else wants to help out, drop me a line. Stephen
From: "__matthewHawthorne" <[EMAIL PROTECTED]> > Don't forget about codehaus.org, they have some cool projects also. But > I'm not sure how hard it is to get a project going over there... > > > > Stephen Colebourne wrote: > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
