On Jan 22, 2013, at 11:03 AM, Matt Neuburg <[email protected]> wrote:
> We have dot-syntax for accessors, and we have dot-syntax for struct elements,
> and we can chain them, but not as an lvalue. It is legal to say
>
> x = object.struct.element
>
> and
>
> object.struct = f
>
> and
>
> struct.element = x
>
> but not
>
> object.struct.element = x
>
> I suppose this is because you can't use the very same accessor as a getter
> and a setter simultaneously, but really it's quite obvious what this means:
> it means means
>
> temp = object.struct
> temp.element = x
> object.struct = temp
>
> So *why* can't the compiler just allow it to mean that, instead of making me
> write it all out by hand? There's no ambiguity as far as I can tell. The ARC
> compiler is supplying plenty of code behind the scenes, including temporary
> variables, so surely it wouldn't be onerous to do the same sort of thing
> here. m.
You are correct that it is absolutely implementable with these semantics. I
think we have bugs open on it already, but you can "vote" by filing a new one.
One obvious concern with supporting this is the fear that somebody's going to
write:
obj.dimensions.x = x;
obj.dimensions.y = y;
obj.dimensions.width = width;
obj.dimensions.height = height;
which is, yes, admittedly convenient, but which is massively less efficient
than the alternative:
obj.dimensions = (struct Dimensions) { x, y, width, height };
both because it does eight message sends instead of one and because it's likely
to cause four separate notifications, three of them totally unnecessary,
instead of one.
John.
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
