On Wed, Jan 30, 2013 at 01:58:16AM +0100, Rob T wrote: [...] > I agree partial emulation can work, and I see you've pointed out > that the usage of a property will have to be restricted so that it > can work, but this means you have to mark your naked variables as > @property ahead of time, otherwise you'll discover that you cannot > replace a naked variable with a property without doing plenty of > re-work. [...]
Why do you have to mark naked variables as @property? Isn't that redundant? As for using struct to implement @property, I like the idea, but it does raise tricky issues about how struct methods reference the parent lexical scope. I don't think it's as simple as just rewriting 'this' to point to the outer scope instead, because it breaks language expectations that 'this' should refer to the immediately-containing struct/class. There's bound to be corner cases that will break because of this. Consider, for example, what happens if the inner struct's methods need to call opAssign of the parent struct for whatever reason. There's also the consideration of what happens if you take the address of the 'pseudo' variable: the inner struct would then be effectively dissociated from the parent struct, and you'll need that hidden context pointer (along with its gotchas) in order to have things still work as before. T -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a. -- Wouter Verhelst
