Clearly Petzold did not do a good enough job explaining what he meant. The operation you describe works perfectly on non-value property gets and behaves as you have outlined on value types.
You are correct that it would have been possible to include a reference to the appropriate objects but that would have added significant complexity to a language where complexity was trying to be reduced/eliminated. > -----Original Message----- > From: dotnet discussion [mailto:[EMAIL PROTECTED]] On Behalf Of > Jon Jagger > Sent: Thursday, May 30, 2002 7:07 AM > To: [EMAIL PROTECTED] > Subject: Re: [DOTNET] Accessor on an accessor not allowed. Why? > > On Thu, 30 May 2002 10:30:07 +0100, Ian Griffiths <[EMAIL PROTECTED]> > wrote: > > >> >> > 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? > > I don't think I provided one. It all stemmed from a paragraph that was in > Petzold book (page 105, 1/3 down, not Richters as I said, sorry): > > "Don't do this however: > Size.Width *= 2; > That's setting a property of a property. For reasons beyond the > comprehension of people who don't write compilers, it's not allowed." > > It seems a resonable expectation that if you have a control c that > contains a Size property you should be able to write > > c.Size.Width *= 2; > > but of course you can't. And there is no work around. It's just not legal. > I can see the logic behind this, that c.Size is a get and so the .Width > set accessor operates on a copy, exactly as you say. > What niggles me is that Petzold seemed to imply there was a deeper reason > than this. And as you also point out, the .Size get could return a struct > (say) that contained a reference back to c and pretended to be a Size > property. In other words it's not completely unimaginable that you might > want to do some work to allow users to be able to write: > > c.Size.Width *= 2; > > But of course you can't because you can't. > > I chose a poor example in my post. A better example is where there sub > poperties are _not_ dependent on each other. Like Width and Height in a > Size. > > [snip] > >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. > > I largely agree. However, many property types are already defined to be > structs. > > >> 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; > > > > But this is not enough. You also have to write it back... > > Size localCopyOfSize = someControl.Size; > localCopyOfSize.Width *= 2; > someControl.Size = localCopyofSize; > > as opposed to > > someControl.Size.Width *= 2; > > (which still won't work) > > Cheers > Jon Jagger > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
