Property discussion wrap-up

[Dmitry Olshansky]

30-Jan-2013 22:05, Zach the Mystic пишет:
> On Wednesday, 30 January 2013 at 17:35:25 UTC, Dmitry Olshansky wrote:
>>> Okay, cool. Two questions remain: 1) How hard to implement structs
>>> nested in structs to mimic ones nested in functions?
>>
>>
>> IMO if property is to be implemented in the library it has to include
>> the field itself. (And I suspect properties should enjoy compiler
>> support).
>>
>> Then something like:
>>
>> struct A{
>>     Property!(int, filter, getter) prop;
>> private:
>>     void func()
>>     {
>>         ...
>>         prop.raw = xxx; //direct write
>>         prop = yyy; //goes through setter
>>     }
>> }
>>
>> where .raw is the field itself and there must be a way to let only
>> struct itself have access to it. I have one method to get this but I
>> don't like it - put this in each module:
>>
>> mixin PropertyForModule!(my_module);
>>
>> introducing a Property template in this module, with private .raw
>> accessible thusly only in this module.
>>
>> Getter is then just any function that maps T => T, with x => x by
>> default so can be omitted.
>>
>> Filter is something new but in essence it works like the following
>> setter:
>>
>> void setter(T)(ref T val, T newVal)
>> {
>>     val =  filter(newVal); //filter may through
>> }
>>
>> It's a bit more restrictive though so feel free to destroy.
>
> Does my suggestion about the compiler detecting a struct with no data
> warm you up a bit to properties as structs? If so, there is really very
> little need for ANY library support. Strangely, implementing
> struct-nested structs with actual data could be a significantly harder
> task than implementing them with no data. No extra pointer need be created.
>
I have one key problem - the hidden pointer detail.
In other words how should it find the instance of the outer struct to to 
access it?

struct A{
	int a;
	struct B{
		void foo(){ a = 42; }
	}	
	B b;
}

A a;
a.b.foo(); //how that b is supposed to know it's outer struct without 
the hidden pointer?

auto x = a.b;
x.foo();// and now what?


> I'll try to summarize the changes required. The first two are necessary.
> The third is for aesthetic reasons, but as in the case of lambda
> functions that could make a huge difference.
>
> 1. Have non-static struct-nested structs be able to refer to their
> parent's data. With no-data structs, I suspect this will be easy, and
> it's actually the primary intended usage, which makes only the corner
> case tricky, where new pointers must be added, etc.
>
> 2. Add opGet to the compiler's list of overloads. It is simply opCall
> but with parens banned instead of mandated.
>
> 3. Enable Highlander structs so that defining a property is as easy as
> define a new-style lamba:
> struct __fooHidden {}
> __fooHidden foo;
>
> simply becomes:
>
> foo struct {}


-- 
Dmitry Olshansky