On Tuesday, 29 January 2013 at 18:54:09 UTC, H. S. Teoh wrote:
> I agree with all of this, except that currently, as things stand, we
> can't actually implement certain kinds of properties as structs, because
> nested structs do not have access to their parent lexical scope:
>
> 	class Rectangle {
> 		float width, height;
>
> 		// Struct implementation of @property
> 		struct AreaProp {
> 			float value() {
> 				// Error: can't access Rectangle.width
> 				// and Rectangle.height
> 				return width*height;
> 			}
> 			alias value this;
> 			...
> 		}
> 		AreaProp area;
> 	}
> 	void main() {
> 		auto r = new Rectangle;
> 		r.width = 2.0;
> 		r.height = 1.5;
> 		writeln(r.area); // in theory, this should work
> 	}
>
> We'd have to move width and height inside the AreaProp struct to make
> this work, but then we're back to square one (you'd need @property to
> implement .area inside AreaProp).
>
>
> T

This can easily be changed, in my opinion. First, have the compiler detect whether the struct has any data members of its own. If not, disallow "this" property and "new" operator. Now "this" is free to use on a parent struct. However, if you later added a data member to the struct, it would break code, so no. But maybe we could use something like "outer.this" instead.

Thank you for agreeing with most what what Rob T said!

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.

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

On Tuesday, 29 January 2013 at 18:54:09 UTC, H. S. Teoh wrote:
[...]
>
> We'd have to move width and height inside the AreaProp struct to make
> this work, but then we're back to square one (you'd need @property to
> implement .area inside AreaProp).
>
>
> T

Yes that's true, and I know structs as they currently stand will need some changes to make this work, but more likely we'll have to introduce a new kind of struct to deal with situations like this.

Zach the Mystic mentions a situation where we wrap not the data, but only the functions around a struct-like property object, that way it contains no data of its own, does not need a "this" or a constructor or destructor. The idea extends  past just implementing properties, and into implementing "smart functions" that can be used in more generalized ways.

--rt

On Tuesday, 29 January 2013 at 21:32:00 UTC, Rob T wrote:
> Zach the Mystic mentions a situation where we wrap not the data, but only the functions around a struct-like property object, that way it contains no data of its own, does not need a "this" or a constructor or destructor. The idea extends  past just implementing properties, and into implementing "smart functions" that can be used in more generalized ways.

I would only add that the function can only be as smart as the programmers who write it...

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.

On Tuesday, 29 January 2013 at 18:54:09 UTC, H. S. Teoh wrote:
> I agree with all of this, except that currently, as things stand, we
> can't actually implement certain kinds of properties as structs, because
> nested structs do not have access to their parent lexical scope:
>
> 	class Rectangle {
> 		float width, height;
>
> 		// Struct implementation of @property
> 		struct AreaProp {
> 			float value() {
> 				// Error: can't access Rectangle.width
> 				// and Rectangle.height
> 				return width*height;
> 			}

You know, I was too dumb to even understand what you wrote when I read it the first time. I was just naively assuming that nested structs were like nested functions. Some rules definitely need to be figured out here. I don't see why the basic functionality which is provided for nested functions couldn't work also for nested structs. Does "static struct" mean anything here? Couldn't it be used exactly like static nested functions? Would it break code if we now forced people to say "static struct" instead of just struct?

I'm sorry for missing your point. I'm trying to suggest advanced language features without even knowing some of the basics. I ask you to bear with me.

On Wednesday, 30 January 2013 at 05:20:51 UTC, Zach the Mystic wrote:
> You know, I was too dumb to even understand what you wrote when I read it the first time. I was just naively assuming that nested structs were like nested functions. Some rules definitely need to be figured out here. I don't see why the basic functionality which is provided for nested functions couldn't work also for nested structs. Does "static struct" mean anything here? Couldn't it be used exactly like static nested functions? Would it break code if we now forced people to say "static struct" instead of just struct?
>
> I'm sorry for missing your point. I'm trying to suggest advanced language features without even knowing some of the basics. I ask you to bear with me.

Wait, hold on there! This says otherwise: http://dlang.org/struct.html

So what's up? Who's wrong!?

On Wednesday, 30 January 2013 at 05:24:56 UTC, Zach the Mystic wrote:
> On Wednesday, 30 January 2013 at 05:20:51 UTC, Zach the Mystic wrote:
>> You know, I was too dumb to even understand what you wrote when I read it the first time. I was just naively assuming that nested structs were like nested functions. Some rules definitely need to be figured out here. I don't see why the basic functionality which is provided for nested functions couldn't work also for nested structs. Does "static struct" mean anything here? Couldn't it be used exactly like static nested functions? Would it break code if we now forced people to say "static struct" instead of just struct?
>>
>> I'm sorry for missing your point. I'm trying to suggest advanced language features without even knowing some of the basics. I ask you to bear with me.
>
> Wait, hold on there! This says otherwise: http://dlang.org/struct.html
>
> So what's up? Who's wrong!?

Okay, so now I'm really foolish! I think my ORIGINAL response, to use "outer", would actually make a lot of sense here! outer.outer.outer... ad infinitum. Not only, but when the struct has no data of its own, the compiler silently eliminates the pointer in question.

On Wednesday, 30 January 2013 at 05:30:47 UTC, Zach the Mystic wrote:
>>> I'm sorry for missing your point. I'm trying to suggest advanced language features without even knowing some of the basics. I ask you to bear with me.
>>
>> Wait, hold on there! This says otherwise: http://dlang.org/struct.html
>>
>> So what's up? Who's wrong!?
>
> Okay, so now I'm really foolish! I think my ORIGINAL response, to use "outer", would actually make a lot of sense here! outer.outer.outer... ad infinitum. Not only, but when the struct has no data of its own, the compiler silently eliminates the pointer in question.

Or just your basic "no shadowing variables" rule to simplify, simplify... I can totally dig that.