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
