> >> > someControl.Size.Width * 2;
> >
> >> But the whole statement might _not_ be pointless.
> >> One of the main points of a property is that a write
> >> context you don't get an assignment you get a set
> >> accessor.
> >
> >Ah, but this isn't a write context.
>
> It was in my original question.
Could you provide the original code fragment then? By the way this:
someControl.Size.Width *= 2;
isn't a write context for the control either. Which is what I actually
meant - I had originally misread the code above and thought it was what I've
just written. But in either case the Control sees a read, not a write.
> >At least it's not for the Size property. This causes a
> >*get* of the Size. It might then perform a set on
> >the size struct's Width, but it'll be a copy of the Size
> > that it performs the set on. And unless the Size were
> > to hold a reference back to its containing object
> > (which would pretty much defeat the purpose of making
> > it a value type in the first place) then there's nothing
> > useful that the Size.Width set accessor can do anyway.
>
> That's a bold statement. I myself don't claim to be
> omnipotent ;-) I can just about image a scenario where it
> might be useful. Consider a _class_ that contains a property
> which is not trivial. Suppose the property contains two sub
> properties that have a mutual constraint (something similar
> cropped in a posting recently).
In which case you would surely want to make them read only, and only allow
them to be modified through a method that sets both simultaneously so that
you can enforce the constraint.
However this is an entirely different issue - it's orthogonal to the
original issue because precisely the same problem applies:
foo.Prop.SetBothSubProps ("foo", "bar");
this is broken for exactly the same reason if Prop is a value type.
Although this time you won't get a warning from the compiler. (Or if you
meant foo.SetBothSubProps("foo", "bar"); then again that's different because
now we don't have the extra level of accessors...)
> In this case you might want to provide a top level property
> _and_ a nested property. In this case making the top level
> property return a struct containing a reference back
> to the object might be a useful optimization.
It seems like a dangerous idea to me - the nature of value types is that
they don't have any real identity. By giving one an 'owner' (i.e. a
reference back to its parent) you sort of change that, but you won't be
changing the fact that value types get copied all over the place. This is
not a show stopper, but it is cause for concern.
Although this could be made to work, it seems like it will be unnecessarily
complex. If the set accessor on the value type always redirects back to the
parent object, how is the parent object ever going to set the value? Unless
you provide a second accessor on the value type to *really* set the value,
in which case how are you going to stop other people from using that?..
(And there's no way that an instance of the value type can know that it's
the 'master copy' in the parent object.) Sure there are workarounds, but it
seems like unnecessary complexity.
But the main thing that worries me about this idea is that this just isn't
how value types usually behave. (With the exception of references, which
are of course stored as value types, and do precisely this. But that's all
they do, and what's more you can't do anything *but* dereference them in
C#...) So technically I don't deny that you could make it work, I just
think it will lead to problems. I would tend to go either with making the
property a reference type, or making its properties read only to prevent the
problem from occurring.
> Bt be that as it may, my question is still is there a _fundamental_
> reason that only compiler writers currently know about (as
> implied by Petzold).
Well you can always do this:
Size localCopyOfSize = someControl.Size;
localCopyOfSize.Width *= 2;
This makes it slightly more obvious what will get modified. And if that's
not what the developer meant, then in that case, no you fundamentally can't
do it. (I've not read the part of Petzold in question yet, so I can't
comment. Although I have the book - if you give me a page number I can be
more specific...)
--
Ian Griffiths
DevelopMentor
You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
