Property discussion wrap-up

[Zach the Mystic]

On Tuesday, 29 January 2013 at 21:23:19 UTC, Rob T wrote:
> 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.

Besides opGet, which would behave *exactly* like opCall except it 
disallows parentheses, what is really missing from structs? If 
you simply look at http://dlang.org/operatoroverloading.html , 
somebody, I don't know who, has completely designed everything 
you could possibly want a property to do. H.S. Teoh mentioned the 
"address of" operator "&". So simple... add opAddress, if 
necessary, to the list!

A @property is nothing more than a poor man's struct, from what I 
can see. I really think Walter should just take it out behind the 
woodshed and do what he has to do.

> 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.

You know, anything, a module, a function, a struct, can contain 
state by declaring a static variable, i.e. "static int foo;" 
which I think is a per thread state. I'm not sure state is as bad 
a problem as you suggest. What would be the difference between 
the state you're talking about and this?

Yes, modules have things in common with structs, but to go the 
whole way, are you suggesting that you want one *module* per 
*property*? No, I don't assume so. Structs could be thought of as 
mini-modules, but at least you can have more than one per file!

> 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.

To define all of the operators for an int property could be quite 
tedious, but a few carefully selected templates in a library 
somewhere, std.property maybe, could probably allieviated most if 
not all of the grunt work of implementing the full suite of 
operators needed to fully simulate a built-in type.