Hey Kevin,
yeah, so probably a better way to 'fix' this whilst maintaining
compatibility for those who like this behaviour would be a system
property that tells the framework itself (when fetching) to expose
unmodifiable lists only perhaps...
How do other people handle this?
On 10/11/2009, at 11:56 PM, Kevin Menard wrote:
> Hi Lachlan,
>
> I think I proposed this once before a few years back. The issue as I
> recall was that there are enough people out there relying on the list
> modification behavior that changing the default would be a
> non-starter. I don't necessarily mind supporting a second set of
> generator templates, however.
Sure - but this is velocity right :-) It could be a property switch
within the same template. Doing this within the templates I'm thinking
is a bit of a work around in the end ... I'm thinking the better long-
term solution would be within the framework itself as mentioned above.
> --
> Kevin
>
> On Tue, Nov 10, 2009 at 2:49 AM, Lachlan Deck
> <lachlan.dec..mail.com> wrote:
>> Hi there,
>>
>> given some stuff we've seen in our own code (and general better
>> practices
>> for dealing with collections in general) I thought I'd suggest the
>> following
>> changes for the default cayenne entity templates:
>> - private ivars rather than protected (if they're not already)
>>
>> - return Collections.unmodifiableList(foo) rather than returning
>> the actual
>> list that's modified via addTo/removeFrom etc.
>>
>> Thoughts? Philosophies?
>>
>> with regards,
>> --
>>
>> Lachlan Deck
>>
>>
>>
>>
with regards,
--Lachlan Deck
This archive was generated by hypermail 2.0.0 : Tue Nov 10 2009 - 14:27:09 EST