xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Smiley <dsmi...@mitre.org>
Subject Re: No Collections API use?
Date Thu, 12 Aug 2004 14:18:24 GMT
I read that document but JDK 1.5 support really is unrelated to what 
I'm talking about.  The more I think about it, Collections API use is 
clearly the right choice.  I don't buy the speed trade-off argument 
Radu makes either.  We're not talking about low-level parsing or 
graphics manipulation code; we're talking about high-level programming 
abstractions.  If after this, one /still/ thinks we should use arrays, 
then I ask to those people, when *does* one use Collections?

I'd like to see this suggestion in the 1.3 section of the V2Features 
document.

~ David Smiley
   MITRE, Dept D520 in Bedford
   781-271-7659
   AIM: dsmiley9

On Aug 11, 2004, at 4:08 PM, Radu Preotiuc-Pietro wrote:

> DavidS, you should also probably take a look at
> http://wiki.apache.org/xmlbeans/V2Features (the part with JDK1.5
> support).
>
> Radu
>
> -----Original Message-----
> From: David Waite [mailto:mass@akuma.org]
> Sent: Tuesday, August 10, 2004 3:23 PM
> To: xmlbeans-dev@xml.apache.org
> Subject: Re: No Collections API use?
>
>
> I can't really speak for things which were decided before my time, but
> I would guess that arrays were chosen over collections because they 1.
> access faster 2. are typed.
>
> -David Waite
>
> On Aug 10, 2004, at 9:24 AM, David Smiley wrote:
>
>> Were standard collection interfaces considered instead of and/or in
>> addition to the current use of Java arrays for the public interfaces
>> generated?  I suspect this design decision was made because it was
>> easier to code keeping potential multi-threaded use in mind.
>>
>> I put a lot of importance on the collections API, so I would favor a
>> future version of XmlBeans that removes all of the list-manipulation
>> methods from generated interfaces implementations and instead has a
>> simple getter for a java.util.List.  This has the benefit of
>> simplifying the API and aligning it with interfaces Java programmers
>> are already familiar with it.  The challenge would be for the
>> implementation to offer performance on par with what we see now.  I
>> think this can be done.  Heck, it sounds like fun to code too!  To
>> minimize generation code, these generated implementations of
>> java.util.List would all extend a base class held in the XMLBeans
>> library which would contain code that would look a lot like what we
>> see now in the generated Impl's but parameterized/genericized.
>>
>> ~ David Smiley
>>   MITRE, Dept D520 in Bedford
>>   781-271-7659
>>   AIM: dsmiley9
>>
>>
>>
>> -
> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
>> For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
>> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
>>
>
> - ---------------------------------------------------------------------
> To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
>



- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/


Mime
View raw message