[TYPO3-mvc] Cloning properties in setter and getter methods of models (blog example)

[Franz Koch]

On 12.02.2011 01:26, Thomas "Thasmo" Deinhamer wrote:
> But then there's still one problem I don't like:
> If a special case arises, where a cloned object
> is returned by the getter, someone maybe expects
> to get the original object as this may be the default.
>
> And let's assume a clone is returned because the EXT
> author wants the developer to use a specific setter
> method of the model, because there's some magic in
> the setter, which would modify stuff etc.
>
> So, the only 'clean' solution to this (= consistent
> API [no cloning], but still the magic modifications
> on new properties) would be to have a method called
> something like persistObject() or similar, which
> would be called before the object gets persisted,
> so the magic could happen there, without the need
> to return any cloned objects and without the need
> to put custom code in the setters.
...
> What's your opinion on that?

I don't think that's needed, is it? In my eyes, a getter returning a 
single object should deliver the original object. I can't imagine a case 
where the parent object has to trigger some special stuff if f.e. the 
name of the childObject changes (how would it keep track of that anyway 
- it's out of it's scope). If tracking of this is needed, then the child 
might have a back reference to the parent object and trigger the 
necessary methods.
The only scenario I currently can imagine where the parent object has to 
be aware of changes is if the object itself get's replaced - and that 
has to be done via the setter anyway where it easily can be tracked.

It's a different thing for objectStorages in my eyes. If there's a 
getter for the whole objectStorage, then this one could return a clone 
if adding or removing objects need to be tracked. If not, there's no 
need to clone anything. And as one is supposed to use available 
addSomeObject/removeSomeObject methods of models anyway, this shouldn't 
be a issue at all. A clone would here just be a safety net for the 
domain logic and shouldn't affect the way you deal/interact with the 
objects.

So I personally don't see any issues with it and don't think we need 
some strict rules for it. But this is again just my point of view and 
would be glad to hear some other opinions.

-- 
kind regards,
Franz Koch