>> (2) changing List to Collection. (-1) Lists are easier to use in the
>> GUI. One thing Cayenne does already is alphabetic ordering of entities
>> and such.
>
> Yes. In some places the framework uses Lists for internal storage, in
> other places it copies mostly Map.values() into a List without ordering.
> If it's unordered you can just as well return a Collection and have the
> client call new SortedList(xxx.getEntities()) - that's why I wrote the
> SortedList (among other things ;). The whole idea was primarily
> motivated by Map.values() returning Collection, and really makes a lot
> of
> dependencies simply vanish since the duplication is gone. In 90% of all
> places the get**AsList methods are simply used for iteration, and it
> would make no difference to the client.
>
> Maintaining both makes matters a lot more complicated and the stepwise
> improvement harder. First you'd need the events to keep things
> consistent (and you need all at once!), but you can only finish these if
> Modeler is kept in sync, and that's hard to do and has big repercussions
> for the rest. I always try to pick the low-hanging fruit first, and
> automated refactorings are just that.
>
> How about this:
> - we keep both
> - use the map.values() reference where possible instead of the expensive
> get**List method
> - the **List methods are kept in there for the remaining callers and
> still return a copy
> - when the event stuff is in place, the list can be cached and becomes
> cheap.
This sounds good. I guess I should also revert -1 to +1 for the original
idea, since it is indeed easy to wrap a collection into a list, if this is
unavoidable (which I hope is not the case).
>> Beta will take at least a few more weeks (I will be on vacation in
>> Europe early April, I hope we can release till then, but I don't have
>> the
>
> Make sure you check out our classic freedom-loving french fries :->
What can I say. In every country (I know of) you have to pay taxes to keep
the politicians that would only embarras you (or worse) :-|
>> Once we are in Beta I would suggest to freeze API and only fix bugs
>> (with Modeler being a possible exception). This is the whole point of
>> Beta.
>
> yes. like I said, alternatively we can put this off until b2 but if you
> think it's still some time off there's no point in wasting time. There's
> little merit in 'freezing' bad API only to break it later anyway. Nobody
> expects something < 1.0 to be stable.
I don't understand. Do you mean that you plan to do this before beta, or
the opposite of that? Also, there will always be "bad" API. I am a big
perfectionist, but we do need to freeze any such changes at some point. Or
we will never go final. Of course it is up to us how to define this
"point".
>> > DataMap:
>> > - rename to getDb/ObjEntities
>> > - return immutable read-through Collection
>> > - remove getDbEntityMap (not used elsewhere)
>> > -or-
>> > - remove *List methods completely
>> > - rename getDb/ObjEntityMap to getDb/ObjEntities
>> > - return immutable read-through Map
>>
>> I'd prefer keep the (renamed) list method, and keep the Map methods
>> (returning immutable maps I guess).
>
> Well this won't give any benefit except for the name cleanups, since
> then the Lists have to maintained, and like you said below this can only
> be done reasonably well when the event stuff is in place. The *List
> methods don't say whether the entities are ordered, and I don't think
> they actually are (will check). But even if they are, the values() will
> be too. Basically this is the same problem as above: >90% of the callers
> of get**List just iterate over it, instead using get**.values().iterator
> would not change a thing for worse.
Ok.
>> > ObjRelationship:
>> > - rename getDbRelationshipList to getDbRelationships
>> > - return immutable List
>
> OK I guess?
Yeah, I don't see a problem with that.
Andrus
This archive was generated by hypermail 2.0.0 : Thu Mar 13 2003 - 16:52:17 EST