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.d...@gmail.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
