Property discussion wrap-up

[Rob T]

On Tuesday, 29 January 2013 at 20:14:29 UTC, Zach the Mystic 
wrote:
> On Tuesday, 29 January 2013 at 17:47:44 UTC, Rob T wrote:
>> The struct property concept is perhaps more profound than the 
>> function-only approach because it can be used for much more 
>> than what was originally intended, For example, any normal 
>> variable can be redefined into a property, allowing you to add 
>> additional state to it, and additional intelligence. 
>> Effectively, you are able to create "smart" variables and use 
>> them in a generalized way.
>
> There is even more then one way to do it, and your new struct 
> need not carry any data of its own:
>
> struct Steve
> {
>   int _n;
>   bool nHasBeenSet;
>   n struct
>   {
>     int opGet() { return _n; }
>     int opAssign( int newN ) {
>       _n = newN;
>       nHasBeenSet = true;
>       return _n;
>     }
>   }
> }
>
> The extra data is outside the struct's property definition. I 
> assume this would be the normal way to do it. Structs have 
> incredible semantics, and they're already in the language. In 
> my opinion, their use as a namespace is under-appreciated.
>
>> The property as a function approach, is not very profound, and 
>> the need for them is not very compelling, especially 
>> considering how much effort is being spend on this topic. The 
>> struct approach however is much more interesting and has much 
>> more potential use.
>>
>> --rt
>
> Thank you for saying that, Rob T.

We can extend the idea to not only think in terms of "smart 
data", but also in terms of "smart processing", where a normal 
function is wrapped up into a struc like object so that it may 
optionally carry it's own data for holding state, and also 
optionally include additional functions for performing various 
additional operations. We can do this already using structs, and 
maybe only a few small tweaks and it's really nice to use.

Same concept as the property, just that we're thinking in terms 
of the processing side of things instead of only the data 
storage. With what we're thinking about here, we can do both in 
one identical package.

Maybe the whole debate concerning @property points out that the 
stuct, and I suppose the class, are missing something, but it's 
not that we need to add properties to them, instead that we need 
to allow them to behave like properties, and perhaps more.

Don't forget about modules in D, the module is a struct like 
concept, although you cannot have multiple instances of a module, 
it does contains state, has a constructor and destructor, has 
private and public members, and can also have properties using 
current @property syntax. It is sort of nested, due to imports of 
other modules (imports the interfaces). It could use improvements 
to the interface, but it looks like a struct in many ways.

Maybe take a look at the struct-like areas in D and think about 
what is needed to make them more versatile, rather than slap on 
extra gadgets to make up for the weaknesses.

--rt