Re: How far with accessors?
Re: How far with accessors?
- Subject: Re: How far with accessors?
- From: Ondra Cada <email@hidden>
- Date: Fri, 28 May 2004 02:06:11 +0200
Marcel,
On 27.5.2004, at 23:25, Marcel Weiher wrote:
>
>> But as far as coding style goes, it seems much less clear what is
>
>> happening,
>
>> and could cause troubles down the line.
>
>
>
> Quite the contrary. You must try to think (as far as possible) in
>
> terms
>
> of the class abstract interface, *not* its internal implementation.
>
>
The -dealloc method *is* part of the implementation.
Sure. Just like -init, in which you seem to support the usage of
accessors.
Does not change the slightest bit the fact that the accessors
encapsulate the usage of whatever they give access to, and therefore
they should be used exclusively: nowhere but in them the actual storage
should be accessed directly (that is, in the normal average case, of
course that each rule has its exceptions).
The trick is that the class is *not* the smallest encapsulation scope;
the encapsulation should be much more finely grained, although it is
not enforced (actually not even explicitly supported) by the compiler.
Nevertheless (save for exceptions, yadda yadda) it is tremendously
beneficial to make the encapsulation scopes small and disjunct. Namely,
(save for..., won't repeat that again), the encapsulation scope of a
property should be defined just by the appropriate accessors, and
that's that. No more, namely not the dealloc.
>
This is your personal opinion, not widely shared.
No. It is an opinion of much wiser (and, far as Cocoa is concerned,
more important) people than me, and it just happens to be shared by me.
By that, I am quitting this part of the debate: it is in archives for
anyone interested.
>
> On the other
>
> hand, had you use just [foo release] instead of the proper [self
>
> setFoo:nil], the simplest change in accessors may break your code.
>
>
No. It would have to be a change in the instance-variable layout.
Wrong. It may be that there is a notification to be sent when a
concrete property value is removed. It may be that there is an
independent storage of weak references, from which the old property is
to be deleted explicitly. There's a world of possible actions to be
taken when the old property value goes poof: you would have us to keep
the track of them explicitly and duplicate them both in the setter and
in -dealloc. If it is your preferred style, all right; myself though, I
prefer to write my code just once and share it. (*)
>
> -(void)setFoo:f { [foo autorelease]; foo=[f copy]; }
>
>
Copying in the accessor is *not* a general pattern, it is applicable
>
only to specific circumstances.
Nope. It is a *very* general pattern; for "has-a" properties (of which
I daresay in practice there's a majority) actually the main and
preferred one.
For a good reason, too: retaining (in other words, sharing) a mutable
property is a *very* dangerous practice, which tends to raise its ugly
head and bite your back at the first upgrade, when you in one module
change the shared value, forgetting meantime there's another module
which shares it, and which would rather keep the original one. (Of
course, with immutables, copying is exactly as cheap as retaining.)
>
It is also not "quicker". Copying objects is potentially very, very
>
expensive.
Sure. Since copy was used in the first accessor variant the very same
way, it self-evidently did not qualify to be the difference which makes
this "quicker".
>
> -foo { return [dict objectForKey:@"foo"]; }
>
> -(void)setFoo:f { if (f) [dict setObject:f forKey:@"foo"]; else [dict
>
> removeObjectForKey:@"foo"]; }
>
>
Excellent example!
Thanks. Am flattered.
>
In this case, he will have a dictionary instance variable, which he
>
can just release with
>
[dict release];
Which does sweet nothing e.g., in case the dictionary happens to be
shared with another object, which stores different things there.
Even if this (or similar) scenario does not apply, still there's the
problem with having to duplicate the setter code, as explained in (*)
above.
Finally, sure, it *is* possible that the class design is such that the
dealloc just *has to be* part of the accessor encapsulation scope:
nobody says it's not. What I am pointing out though is that it is an
*exception*, whilst the normal case, the rule, is that accessors could
not (and should not) include dealloc into their encapsulation scope.
---
Ondra Hada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.