commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arron Bates <ar...@keyboardmonkey.com>
Subject Re: [collections] - Few more collections for the masses... (impor tant for Struts view objects, maybe other projects)
Date Fri, 17 May 2002 17:28:29 GMT
James Strachan wrote:

>I don't claim to have fully grokked the reason for the Reserve* collections
>yet but shouldn't they take a Factory object instead of a Class instance and
>array of argument types and an array of argument instances? Something along
>these lines...
>
>public interface Factory {
>    Object createObject();
>}
>

Yup, great idea. Was going to do this, but I thought people would balk 
more for me creating more interfaces for people to use. Ready to go if 
it's the general consensus.

>It'd make them a bit more reusable. Passing in a Class and argument
>types/instances arrays seems a bit of a special case of how to create new
>object instances. Also folks might want to handle exceptions differently -
>making the construction pluggable might make sense.
>

My first step was to make it easy to use. If it's not easy to understand 
and use, then people simply wont use it. I don't see these particular 
exceptions as show stoppers, but that's just an opinion. In terms of 
ease of use, I think that the currect classes are fine. Future-proofing 
is great, but there has to be a future. All of these ideas and such, 
like those from Paul are great. But there was no like class like these. 
First they have to be made. If they become popular, people will come and 
make sure of the definition of their needs.

Just trying to be pragmatic.

>Also are these collections 'lazy'?  i.e. is their point to lazily construct
>elements as they are asked for, on demand, in the same way as the lazy
>initialization pattern for bean properties? Maybe calling them lazy might be
>better then?
>

Lazy says nothing about having the collection expand, or reserve spaces 
for called objects, not set objects. Lazy would say more of the 
collection itself than how it manages things.



Arron.


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


Mime
View raw message