www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP4: Properties

reply "Nick Sabalausky" <a a.a> writes:
 An alternate usage/definition syntax for properties.

http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP4

Note that there are a few parts marked NEED HELP, that could use assistance 
from someone with more expertise in this than me.
Jul 23 2009
next sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Nick Sabalausky wrote:
  An alternate usage/definition syntax for properties.
 
 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP4
 
 Note that there are a few parts marked NEED HELP, that could use assistance 
 from someone with more expertise in this than me.
 
 

Have you checked out haXe's syntax for properties? http://haxe.org/ref/properties It's not very sugary, but it doesn't add new keywords and it handles inheritance nicely (to change the prop's behavior in a subclass, just inherit its methods). The other caveat I can think of is that the grammar might need to change a bit before haXe's properties could be used in D, mostly because haXe's declarations are like this: var Identifier : Type; whereas D does decls like so: Type Identifier So perhaps we could have a grammar like this? PropertyDecl: Type Identifier '{' Getter ',' Setter '}' ';' Getter: null default FunctionIdentifier Setter: null default FunctionIdentifier At some point (semantic analysis?) the compiler needs to make sure the functions used in the property have the correct signature. Type foo(); for getter, Type foo(Type); for setter. Something like int foo{default,default}; could be optimized into int foo; though it should otherwise have the semantics of a property and not of a field (e.g. &foo is not allowed or you get a special property struct or somesuch). I also second the importance of whatever Andrei was talking about with respect to properties in some thread a while ago. It was something about potentially needing 3 different accessors for a property due to some inconsistency or potential for pessimization. I forget what exactly. I remember him having difficulty fitting properties into D2's setup for generic algorithms. It would be nice to get that right.
Jul 24 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message 
news:h4cv6h$st6$1 digitalmars.com...
 Have you checked out haXe's syntax for properties?
 http://haxe.org/ref/properties

Yes, in fact, I've been using haxe a lot lately for work. It certainly beats AS2 and PHP, but there's still a lot about it I really dislike, and it's property syntax is one of my biggest complaints. For those not familiar with haxe, compare the following property in my current D proposal, the equivilent C#, and the equivilent haxe: -------------------------------- // D, current DIP4 public int foo { get { return value; } set { value = set; } } -------------------------------- // C# private int _foo; public int foo { get { return _foo; } set { _foo = value; } } -------------------------------- // Haxe public foo(get_foo,set_foo):Int; private _foo:Int; private get_foo():Int { return _foo; } private set_foo(value:Int):Int { _foo = value; return value; } -------------------------------- That's absolutely horrific for anyone who even remotely values DRY and readability (and formatting the the getters/setters on multiple lines doesn't help). There are a bunch of problems with it, but the one that really sticks out to me is: why in the world should I have to specify special getter/setter names for every single property? What in the world is the point of that? That's like being expected to specify a special name for every 'if' block in the program. I don't want or need a special name, just give me a damn if/getter/setter/whatever!
Jul 24 2009
next sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Nick Sabalausky wrote:
 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message 
 news:h4cv6h$st6$1 digitalmars.com...
 Have you checked out haXe's syntax for properties?
 http://haxe.org/ref/properties

Yes, in fact, I've been using haxe a lot lately for work. It certainly beats AS2 and PHP, but there's still a lot about it I really dislike, and it's property syntax is one of my biggest complaints. For those not familiar with haxe, compare the following property in my current D proposal, the equivilent C#, and the equivilent haxe: -------------------------------- // D, current DIP4 public int foo { get { return value; } set { value = set; } } -------------------------------- // C# private int _foo; public int foo { get { return _foo; } set { _foo = value; } } -------------------------------- // Haxe public foo(get_foo,set_foo):Int; private _foo:Int; private get_foo():Int { return _foo; } private set_foo(value:Int):Int { _foo = value; return value; } -------------------------------- That's absolutely horrific for anyone who even remotely values DRY and readability (and formatting the the getters/setters on multiple lines doesn't help). There are a bunch of problems with it, but the one that really sticks out to me is: why in the world should I have to specify special getter/setter names for every single property? What in the world is the point of that? That's like being expected to specify a special name for every 'if' block in the program. I don't want or need a special name, just give me a damn if/getter/setter/whatever!

Good point.
Jul 24 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Nick Sabalausky, el 24 de julio a las 16:16 me escribiste:
 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message 
 news:h4cv6h$st6$1 digitalmars.com...
 Have you checked out haXe's syntax for properties?
 http://haxe.org/ref/properties

Yes, in fact, I've been using haxe a lot lately for work. It certainly beats AS2 and PHP, but there's still a lot about it I really dislike, and it's property syntax is one of my biggest complaints. For those not familiar with haxe, compare the following property in my current D proposal, the equivilent C#, and the equivilent haxe: -------------------------------- // D, current DIP4 public int foo { get { return value; } set { value = set; } }

I think you have good points about not repeating yourself, but I still find it too magical. I think I prefer something a little more explicit, even if I have to repeat myself. And I think there should be a way to get the real underlaying variable easily. What about: public int foo: _foo { get { return _foo; } set(v) { _foo = v; } } Then, when you want to use the real internal variable, you just use _foo. Even when you are repeating yourself, the internal implementation and the external interface are decoupled; you can rename the property to bar without changing the implementation: public int bar: _foo { get { return _foo; } set(v) { _foo = v; } } The default protection attribute for underlaying property variables are private, but you can change it with: public int bar: protected _foo { get { return _foo; } set(v) { _foo = v; } } I think is is not much harder to write and maintain comparing with what you proposed, but I find it a lot more explicit and thus clear. You don't have to remember where that automagically variables came from. You can implement properties without even a real storage variable using your form: public int baz // readonly { get { return 1; } } What do you think? -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- PROTESTA EN PLAZA DE MAYO: MUSICO SE COSIO LA BOCA -- Crónica TV
Jul 24 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Leandro Lucarella" <llucax gmail.com> wrote in message 
news:20090724212800.GA2120 homero.springfield.home...
 I think you have good points about not repeating yourself, but I still
 find it too magical. I think I prefer something a little more explicit,
 even if I have to repeat myself.

I assume you're referring to the automatic "value" and "set" variables here, right? The proposal seems to be getting a lot of complaints about those. But, I haven't seen any explanations of actual problems with them beyond "it's magical", "I prefer", etc (unless I've overlooked something, and my apologies if I have). Any abstraction could be argued to be "magical". I'm getting the impression that this may be a case of an idea meeting resistance more from being different than from lack of merit. Of course, it could also be that I'm just being overprotective of a bad idea. Can you or someone else provide a more detailed argument/example/explanation for a problem with these automatic vars? As I do seem to be the only one in favor of these automatic vars though, I am willing to omit them from the proposal in the interest of (hopefully) getting at least *something* better than the current state. But, I would hate to have to do so without having been presented a deeper argument against them.
 And I think there should be a way to get
 the real underlaying variable easily.

I was thinking something through traits (which does need to be cleaned up anyway). Although, Robert's post has reminded me of the importance of using properties as readonly views to private data that's modifiable by potentially any member of the class. Using traits would indeed be way too clumsy in that case. But, I do have a solution to that particular scenario: public int foo { // default is whatever is used up above // (public in this case) // but, more permissive is not allowed // (like a protected prop with a public getter/setter) public get { return value; } // I'm using the default setter here just for the // heck of it, but you wouldn't have to. private set; } Then, anything in the class could set the internal value with just "foo", and anything else couldn't. And that setter could probably be automatically inlined. Obviously this doesn't take of all cases where one would need to directly access the property's internal data - something else would need to be created for that (like traits or something). But it does take care of what, to my knowledge, is the only non-optimization-related reason to do so. And, if this still wasn't good enough, you could just go C# style anyway (see below).
 What about:

 public int foo: _foo
 {
    get { return _foo; }
    set(v) { _foo = v; }
 }

 Then, when you want to use the real internal variable, you just use _foo.

At this point, I think it would be good to make a clear distinction between the following issues: 1. Internal storage: auto-named or manually-named? 2. Setter parameter: auto-named or manually-named? 3. Actual syntax for manually-named internal storage. 4. Actual names for auto-named internal storage and auto-named setter parameter. The #4 is the most bike-sheddy, so I'd like to not get too deep into that for now. I'm also going to hold off on #2 at the moment since it's very similar to #1, and #1 seems to be getting more attention. Although, to the end of holding off on #2, I'm going to omit setters from my code samples below. The intent of the examples should still be perfectly clear with just the getter. So, regarding #3 (just to it out of the way, at least for this particular post), there's another syntax idea I have for that (incorporating the "auto" idea from someone else): public int foo { auto _foo; // int, in this case get { return _foo; } //setter here } public int bar { bool isCached=false; // Any other arbitrary var get { /* do expensive work to get value and cache it */ } // maybe a setter here } (This actually makes me wonder about maybe exploring a more struct-derived approach...?) *If* manually-named internal storage is used, then I like both your syntax and the above. Compared to yours, the above is more flexible, but it's also more verbose and might be complete overkill anyway. As for #1, auto-vs-manual naming of the internal storage, consider this: Even though my original DIP4 proposal provides an automatic "value" for internal storage, there is nothing in the proposal that would prevent anyone from opting-out and going C#-style: private int _foo; public int foo { get { return _foo; } // Note also, that the automatic "value" // could be optimized away in these cases. } So, barring any implementation problems I may have overlooked, under my original DIP4, issue #1 becomes purely a matter of personal style. I'm not bondaged and disciplined into making redundant names, and you're not bondaged and disciplined into sticking with a pre-determined name.
 Even when you are repeating yourself, the internal implementation and the
 external interface are decoupled; you can rename the property to bar
 without changing the implementation:

 public int bar: _foo
 {
    get { return _foo; }
    set(v) { _foo = v; }
 }

True, but for anyone using the "myVar : _myVar" naming convention, changing one without changing the other would create . But, that's admittedly a minor issue, and on the whole it's certainly better than the C#-style I mentioned before. Maybe a hybrid approach would be in order? Take your syntax, but the " : _foo" part is optional. And when it's omitted, "value" (or whatever) is used as the default. Except...if you're using that syntax to create a name that the whole class can access, then that would be non-unique (and therefore a problem)...So...What about making the " : _foo " name optional *and* only accessible within the property *and* adding in my idea above about "private set {}"? Ie: Hmm, also, I'm going to make two alternates, A and B, not sure which would be better: class FooClass { public int foo : _foo { get { return _foo; } set; // Ehh, I'm just gonna use the default setter here } public int bar { get { return value; } private set; } public func() { int x; x = foo; // Ok (public getter) foo = 5; // Ok (public setter) x = bar; // Ok (public getter) bar = 5; // Ok (private setter) x = value; // Error: Undeclared token value = 5; // Error: Undeclared token x = bar.traits.internalProp; // Ok (but syntax is probably wrong) bar.traits.internalProp = 5; // Ok (but syntax is probably wrong) // Not sure which of these to do... version(A) { x = _foo; // Ok (internal value) _foo = 5; // Ok (internal value) } version(B) { x = _foo; // Error: Undeclared token _foo = 5; // Error: Undeclared token } x = foo.traits.internalProp; // Ok (but syntax is probably wrong) foo.traits.internalProp = 5; // Ok (but syntax is probably wrong) } } void main() { auto fc = new FooClass(); auto f = foo; // Ok (public getter) foo = 5; // Ok (public setter) auto b = bar; // Ok (public getter) bar = 5; // Error: Setter is private auto _f = _foo; // Error: Undeclared token _foo = 5; // Error: Undeclared token auto _v = value; // Error: Undeclared token value = 5; // Error: Undeclared token } In fact, unless there's real immediate objections, or some obvoious problem I'm missing, I may just include all of those ideas into a new version of the DIP. Language experts: Would there be parsing ambiguities with this "int propertyName : internalName" syntax?
 The default protection attribute for underlaying property variables are
 private, but you can change it with:

 public int bar: protected _foo
 {
    get { return _foo; }
    set(v) { _foo = v; }
 }

Sounds good.
 I think is is not much harder to write and maintain comparing with what
 you proposed, but I find it a lot more explicit and thus clear. You don't
 have to remember where that automagically variables came from.

I don't understand what's there that's non-trivial to remember. I've never seen any problem with C# users knowing/remembering where "value" comes from in their setters (but note of course, that C#'s "value" var is more like the "set" var in my proposal). And with D's magical $ for length, all of the worries people had about "people aren't going to know that!" "They'll have to remember that!", since that feature was implemented it's gotten used *constantly* and I'm not even aware of once single case where it actually ended up being a problem for anybody. These are not the sorts of things that are difficult to remember. And I'm a person who is notoriously bad at memorization!
 You can
 implement properties without even a real storage variable using your form:

 public int baz // readonly
 {
    get { return 1; }
 }

Agreed
 What do you think?

See everything above ;)
Jul 25 2009
parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:h4ecb4$m7g$1 digitalmars.com...
 True, but for anyone using the "myVar : _myVar" naming convention, 
 changing one without changing the other would create . But, that's 
 admittedly a minor issue, and on the whole it's certainly better than the 
 C#-style I mentioned before.

Oops! I guess that's a *really* minor issue ;) What I meant to say before forgetting to proofread was "...changing one without changing the other would usually create an ugly inconsistent break from style, or result in the internal var having a name that's no longer appropriate or consistent with updated project terminology. But..." Or something like that anyway...Not that it really matters all that much...
Jul 25 2009
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 25 Jul 2009 03:29:01 -0400, Nick Sabalausky <a a.a> wrote:

 "Leandro Lucarella" <llucax gmail.com> wrote in message
 news:20090724212800.GA2120 homero.springfield.home...
 I think you have good points about not repeating yourself, but I still
 find it too magical. I think I prefer something a little more explicit,
 even if I have to repeat myself.

I assume you're referring to the automatic "value" and "set" variables here, right? The proposal seems to be getting a lot of complaints about those. But, I haven't seen any explanations of actual problems with them beyond "it's magical", "I prefer", etc (unless I've overlooked something, and my apologies if I have). Any abstraction could be argued to be "magical".

I haven't read all the replies yet, but the one issue I have is similar to the array's magical length property: struct S { int value; int prop { get() { return value; // ambiguous } } } If you used something that was not a variable name (like the fix for arrays -- $) then you do not have a conflict. But I like the idea that Leandro brought up best. One other issue that his idea solves -- in an internal private method, you might want to use the underlying storage directly instead of calling the property for performance reasons, this would be difficult to address with a context keyword. -Steve
Jul 26 2009
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Andrei and Rainer have come up with an alternative that might work.
Addressing the points in the Rationale section:

* It may or may prevent unintended usage depending on how it's
implemented, but will certainly CONVEY the expected usage.

* As above, it may or may not solve the ambiguous code problem depending
on implementation details.

* +=, -=, etc.: I've said before that this should be addressed separately.

* It makes properties discoverable.

* There is a solution to the DRY problem.

Basically, the idea is that this:

interface I
{
    int foo();
    int foo(int);
}

becomes:

interface I
{
    int opGet_foo();
    int opSet_foo(int);
}

As I said, this addresses most of the problems: IDEs and debuggers can
simply look for opGet/opSet pairs.  It's extensible since we can add
more "operators" in the future, AND it plays nicely with inheritance.

The problem is that it still violates DRY.  However, I knocked together
a basic prototype property generator that helps alleviate this:

http://gist.github.com/154755

Possible implementations of the above:

class A : I
{
    // Automatic getter, setter and storage
    mixin( Property!(int, "foo") );
}

class B : I
{
    // Fully custom with custom storage and protection
    mixin( Property!(int, "foo",
        q{
            return storage*100;
        },
        q{
            return storage=value/100;
        }
    ));
}

With a more sophisticated template, it could probably be simplified even
further.

The nice thing about this is that it accomplishes the goals of the DIP
without introducing ANY new syntax.  It does still require compiler
changes to map a.b to a.opGet_b and a.b=c to a.opSet_b(c), but it would
hopefully be more palatable to Walter.

If you want, I can write this up as an alternative solution to the DIP.

Rainer's post: news://news.digitalmars.com:119/h4dpoq$2hpu$1 digitalmars.com
Andrei's post: news://news.digitalmars.com:119/h4dscd$2n7f$1 digitalmars.com
My response to Andrei's post:
news://news.digitalmars.com:119/h4ej0g$11p7$1 digitalmars.com
Jul 25 2009
next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
I do think this proposal is better than what we have since it meets the 
major requirements, but have one minor point of critique:

Offering a mixin is not a good enough argument to address the DRY 
shortcoming. While it may be acceptable in many cases, it is ugly and messes 
with reporting of errors, debugging, code coverage and profiling.
Jul 25 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Lutger wrote:
 I do think this proposal is better than what we have since it meets the 
 major requirements, but have one minor point of critique:
 
 Offering a mixin is not a good enough argument to address the DRY 
 shortcoming. While it may be acceptable in many cases, it is ugly and messes 
 with reporting of errors, debugging, code coverage and profiling.

Very true. We really need to come up with a way to fix this. That said, I sometimes think that string mixins will NEVER get fixed unless Walter has a strong impetus to do so: i.e., people are using them and hurting. But that's another DIP for another day. :P
Jul 25 2009
parent Lutger <lutger.blijdestijn gmail.com> writes:
Daniel Keep wrote:

 
 
 Lutger wrote:
 I do think this proposal is better than what we have since it meets the
 major requirements, but have one minor point of critique:
 
 Offering a mixin is not a good enough argument to address the DRY
 shortcoming. While it may be acceptable in many cases, it is ugly and
 messes with reporting of errors, debugging, code coverage and profiling.

Very true. We really need to come up with a way to fix this. That said, I sometimes think that string mixins will NEVER get fixed unless Walter has a strong impetus to do so: i.e., people are using them and hurting. But that's another DIP for another day. :P

I'm very curious when that day arrives what it could bring. AST macros may help with some issues, but this kind of trickery seems to me inherently unfriendly for tools and maintainers alike. Not that it's a bad thing though, you have to make some trade-offs somewhere.
Jul 25 2009
prev sibling next sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Daniel Keep wrote:

 Basically, the idea is that this:
 
 interface I
 {
     int foo();
     int foo(int);
 }
 
 becomes:
 
 interface I
 {
     int opGet_foo();
     int opSet_foo(int);
 }

It's a little better. But there's still ambiguity: interface I { int foo; int opSet_foo(int); } foo = 5; // which foo is used? To fix that one, you need to report an error when both a var and a property of the same name are declared. Even though they don't have the same name in the interface. interface I { int opGet_foo(); void delegate() opGet_opGet_foo(); } auto x = opGet_foo; Is that the function or the property? Well, perhaps this is not an actual ambiguity in D. But it sure isn't pretty: auto x = opGet_foo; // it's the property auto x = opGet_foo(); // it may be either? auto x = &opGet_foo; // it's the function I just don't understand this resistance against a dedicated property syntax. -- Michiel Helvensteijn
Jul 25 2009
next sibling parent Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
I think I made a few mistakes in the D code, but the point stands.

-- 
Michiel Helvensteijn
Jul 25 2009
prev sibling next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Michiel Helvensteijn wrote:
 ...
 
 It's a little better. But there's still ambiguity:
 
 interface I {
     int foo;
     int opSet_foo(int);
 }
 
 foo = 5; // which foo is used?
 
 To fix that one, you need to report an error when both a var and a property
 of the same name are declared. Even though they don't have the same name in
 the interface.

I think this would NEED to be an error to keep the compiler from going insane. I don't see how this is appreciably different to a+b suddenly being rewritten as a.opAdd(b).
 ...
 
 I just don't understand this resistance against a dedicated property syntax.

You have to be careful: adding syntax increases the complexity of the language. Sometimes it's worth it, sometimes it isn't. If we can do it without adding syntax and it's not too onerous then we probably should.
Jul 25 2009
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-07-25 06:10:09 -0400, Michiel Helvensteijn 
<m.helvensteijn.remove gmail.com> said:

 It's a little better. But there's still ambiguity:
 
 interface I {
     int foo;
     int opSet_foo(int);
 }
 
 foo = 5; // which foo is used?

In the other thread, I suggested this, which could aleviate the problem: int foo.opGet(); // getter void foo.opAssign(int); // setter with some support from the compiler. It could even be exteded to support more: int foo.opIndex(int); // foo[1]; void foo.opAddAssign(int); / foo += 1; void foo.invert(); // special function attached to property Basically, all you need to implement properties is not a dedicaced "property" syntax, it's a syntax to implement some kind of local namespace, and am "opGet" or "opValue" operator for representing the local namespace. It could also be expressed like this: namespace foo { int opGet(); // getter void opAssign(int); // setter ... int opIndex(int); // foo[1]; void opAddAssign(int); / foo += 1; void invert(); // special function attached to property } In both cases, the result would be the same: foo = 1; // same as foo.opAssign(1); return foo; // same as return foo.opGet(); -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jul 25 2009
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-07-25 07:00:32 -0400, Michel Fortin <michel.fortin michelf.com> said:

 	namespace foo {
 		int opGet(); // getter
 		void opAssign(int); // setter
 		...
 		int opIndex(int); // foo[1];
 		void opAddAssign(int); / foo += 1;
 		void invert(); // special function attached to property
 	}

I just want to clarify that I used "namespace" as a keyword in this example to better illustrate the fact that there is no more magic or special syntax under the hood than with a C++ namespace. I'm not actually suggesting we use a "namespace" keyword, I think it'd be confusing. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jul 25 2009
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Michel Fortin wrote:
 On 2009-07-25 06:10:09 -0400, Michiel Helvensteijn 
 <m.helvensteijn.remove gmail.com> said:
 
 It's a little better. But there's still ambiguity:

 interface I {
     int foo;
     int opSet_foo(int);
 }

 foo = 5; // which foo is used?

In the other thread, I suggested this, which could aleviate the problem: int foo.opGet(); // getter void foo.opAssign(int); // setter with some support from the compiler. It could even be exteded to support more: int foo.opIndex(int); // foo[1]; void foo.opAddAssign(int); / foo += 1; void foo.invert(); // special function attached to property Basically, all you need to implement properties is not a dedicaced "property" syntax, it's a syntax to implement some kind of local namespace, and am "opGet" or "opValue" operator for representing the local namespace. It could also be expressed like this: namespace foo { int opGet(); // getter void opAssign(int); // setter ... int opIndex(int); // foo[1]; void opAddAssign(int); / foo += 1; void invert(); // special function attached to property } In both cases, the result would be the same: foo = 1; // same as foo.opAssign(1); return foo; // same as return foo.opGet();

If property is going to be extended like this, why not just make a nested struct. Works even now.
Jul 25 2009
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-07-25 08:07:56 -0400, KennyTM~ <kennytm gmail.com> said:

 Michel Fortin wrote:
 
 In the other thread, I suggested this, which could aleviate the problem:
 
     int foo.opGet();        // getter
     void foo.opAssign(int); // setter
 
 with some support from the compiler.
 
 It could even be exteded to support more:
 
     int foo.opIndex(int); // foo[1];
     void foo.opAddAssign(int); / foo += 1;
     void foo.invert(); // special function attached to property
 
 Basically, all you need to implement properties is not a dedicaced 
 "property" syntax, it's a syntax to implement some kind of local 
 namespace, and am "opGet" or "opValue" operator for representing the 
 local namespace. It could also be expressed like this:
 
     namespace foo {
         int opGet(); // getter
         void opAssign(int); // setter
         ...
         int opIndex(int); // foo[1];
         void opAddAssign(int); / foo += 1;
         void invert(); // special function attached to property
     }
 
 In both cases, the result would be the same:
 
     foo = 1; // same as foo.opAssign(1);
     return foo; // same as return foo.opGet();
 

If property is going to be extended like this, why not just make a nested struct. Works even now.

Close, but a nested struct doesn't have access to the outer class, nor can you override its functions in a derived class. I'd say what I'm proposing is closer to a named mixin: class Z { int x; template Property() { void opAssign(int v) { x = v; } void opAddAssign(int v) { x += v; } int get() { return x; } alias get this; } mixin Property property; } Z z = new Z; z.property = 1; // works! What doesn't work here is the "alias get this" line: you're still forced to explicitly call the getter. And I have the feeling that overriding in a derived class won't work either. Oh and the syntax isn't great at all. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jul 25 2009
prev sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
I really like this idea.

It's pleasing to the eye and very general, much more so than typical
properties are.  The only thing it doesn't solve is the optional
implicit backing storage to satiate all of the DRY fans.
Jul 25 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Chad J wrote:
 I really like this idea.

Which? Andrei
Jul 25 2009
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-07-25 15:13:06 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Chad J wrote:
 I really like this idea.

Which?

His message was in reply to mine: <http://digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=93842> Although there are two syntax proposals in there... I'd guess it's the second one. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jul 25 2009
prev sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Andrei Alexandrescu wrote:
 Chad J wrote:
 I really like this idea.

Which? Andrei

That whole post I replied to.
     int foo.opIndex(int); // foo[1];
     void foo.opAddAssign(int); / foo += 1;
     void foo.invert(); // special function attached to property 

Or as I see it working in the more verbose case: T foo.opAssign(T bar) { // code goes here. } If namespaces lead to that kind of ability then they seem pretty nifty.
     namespace foo {
         int opGet(); // getter
         void opAssign(int); // setter
         ...
         int opIndex(int); // foo[1];
         void opAddAssign(int); / foo += 1;
         void invert(); // special function attached to property
     } 

That seems pretty useful. Maybe it doesn't have to be namespace. Use scope or auto instead. scope seems appropriate, though it may be asking for ambiguities. I can live without this though if it is too drastic.
Jul 25 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message 
news:h4fjiu$2pbr$1 digitalmars.com...
 The only thing it doesn't solve is the optional
 implicit backing storage to satiate all of the DRY fans.

As far as I can tell, that seems to only be me :/
Jul 25 2009
parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Nick Sabalausky wrote:
 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message 
 news:h4fjiu$2pbr$1 digitalmars.com...
 The only thing it doesn't solve is the optional
 implicit backing storage to satiate all of the DRY fans.

As far as I can tell, that seems to only be me :/

I appreciate it too. I suppose it's not super-important to me because I am willing to eat a bit of cruft for the sake of progress, but yeah, I would like to see some kind of implicit backing to make things less hackey looking in my code.
Jul 25 2009
prev sibling next sibling parent Piotrek <starpit tlen.pl> writes:
Daniel Keep pisze:
 interface I
 {
     int opGet_foo();
     int opSet_foo(int);
 }

 
 If you want, I can write this up as an alternative solution to the DIP.

Vote++ Personally, this is my No.1 so far. Cheers Piotrek
Jul 25 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
news:h4ejrk$12vv$1 digitalmars.com...
 Andrei and Rainer have come up with an alternative that might work.

 Basically, the idea is that this:

 interface I
 {
    int foo();
    int foo(int);
 }

 becomes:

 interface I
 {
    int opGet_foo();
    int opSet_foo(int);
 }

My admittedly sarcastic thoughts on this whole group of property proposals (and pardon my grumpiness): A 'for' loop is great, but one of the most common uses for it is to iterate over a collection. And for that, there are certain issues with using 'for' that other languages have solved by adding a special 'foreach'. But, I see no reason to add a special 'foreach' syntax (and certainly not a new keyword!), because we have most of what we need for 'foreach' in place already: class Foo { int[] content; Iterator opIterator() { return new Iterator(); } class Iterator { private index=0; int opGetNext() { return content[index++]; } bool opHasNext() { return index < content.length; } } } void main() { auto f = new Foo(); // populate f int index; int val; auto iter = f.opIterator(); for(int index=0, int val=iter.opGetNext(); iter.opHasNext(); index++, val=iter.opGetNext()) { // Use index and val } } Granted, that's ugly and won't satisfy the people who like DRY and brevity, but we can solve that with mixins: class Foo { int[] content; mixin(iterator!(int, q{ private index=0; }, q{ return content[index++]; }, q{ return index < content.length; }, )); } void main() { auto f = new Foo(); // populate f mixin(foreach!(f, int, "val", "index", q{ // Use index and val } )); } And then everybody loves this new idea because it's so D-like and makes minimal changes to the syntax/compiler. And then we all spend every weekend wondering why the hell nobody wants to use our wonderful language. Don't get me wrong, using these "foo.opGet" ideas for *behind-the-scenes implementation* of properties sounds like it may very well be the right way to go. But without a real dedicated syntax to cover it all up, it's just idiotic.
Jul 25 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Excused.  :D

Look at it from a practical standpoint: it *would* be nice to have
dedicated syntax, but Walter *is opposed to it*.  He doesn't see the
need for it.

I think I'm like him in this respect: he wants to find a way of doing
this without having to actually extend the language.

If Walter becomes convinced that properties DO need improvement AND
deserve special syntax, then hooray!  The proposal I brought up is
superfluous and can be discarded.

But we know he's currently against adding syntax.  So he might reject
your proposal.  That's where the one I posted about comes in: it
*doesn't* require syntax changes to the language; it improves properties
the best we can without doing adding syntax.

If he rejects yours, maybe he'll be more receptive to the alternative.
Yes, it's not as syntactically nice as yours, but it's STILL an improvement.

And yeah, mixins are ugly.  But if no one ever uses them, they'll never
improve.  Maybe if lots of code is using them, Walter will be inclined
to work on macros to improve the situation.

Some improvement is better than none.  Sometimes you have to compromise.
 I don't think we should ignore or demonise viable alternatives because
they're not what we specifically wanted.
Jul 26 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
news:h4i0tu$hig$1 digitalmars.com...
 Look at it from a practical standpoint: it *would* be nice to have
 dedicated syntax, but Walter *is opposed to it*.  He doesn't see the
 need for it.

 Some improvement is better than none.  Sometimes you have to compromise.
 I don't think we should ignore or demonise viable alternatives because
 they're not what we specifically wanted.

I suppose you have a good point. Although I felt like I was compromising plenty just with being willing (if necessary) to abandon the automatic internal storage... :/ (I really want that! :) ) I am convinced though, if properties get done in this Walter-friendly manner, it'll become yet another in the list of prospective user's complaints about D. "Yea, I looked at D. Have you seen the syntax for creating properties? OMG, what were they thinking?!"
Jul 26 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Nick Sabalausky wrote:
 "Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
 news:h4i0tu$hig$1 digitalmars.com...
 Look at it from a practical standpoint: it *would* be nice to have
 dedicated syntax, but Walter *is opposed to it*.  He doesn't see the
 need for it.

 Some improvement is better than none.  Sometimes you have to compromise.
 I don't think we should ignore or demonise viable alternatives because
 they're not what we specifically wanted.

I suppose you have a good point. Although I felt like I was compromising plenty just with being willing (if necessary) to abandon the automatic internal storage... :/ (I really want that! :) ) I am convinced though, if properties get done in this Walter-friendly manner, it'll become yet another in the list of prospective user's complaints about D. "Yea, I looked at D. Have you seen the syntax for creating properties? OMG, what were they thinking?!"

Actually, what I'd like to see is this syntax: mixin properties! q{ int foo = 42 { get; set { notify(); storage = value; } } }; The only reason we HAVE to use a string mixin here is that you can't have protection attributes in a mixin template; they get applied to within the scope of the template, not the scope of where they're being mixed in. Pity we can't do: `private(scope) T storage;` or somesuch to escape the protection... As for parsing the string, I suspect that it's possible, but all my experiments into CTFE-based parsing of D code has shown it to be incredibly fiddly and painful.
Jul 26 2009
prev sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Daniel Keep wrote:
 ...
 And yeah, mixins are ugly.  But if no one ever uses them, they'll never
 improve.  Maybe if lots of code is using them, Walter will be inclined
 to work on macros to improve the situation.
 ...

I'd be kinda surprised if Walter is reading all of this and not thinking, "hmmmm, maybe I should fix this someday." Everyone is saying mixins are ugly. Ugly to the point where they obfuscate your code. And it sounds like only a handful of people are using them (hence arguments trying to convince people to use them). Clue by four. At some level I think Walter saw this coming a long time ago, hence talk of AST macros. Too bad they are probably too difficult for a D2 release. Maybe mixins are supposed to be ugly and only useful for optimization hacks and such, but not really intended to allow the language to extend itself. This actually fits better with my memory of the mood surrounding their creation. *shrug* At the end of all of this, I don't find myself feeling like using mixins unless I really have to.
Jul 26 2009
prev sibling next sibling parent reply BLS <windevguy hotmail.de> writes:
Nick Sabalausky wrote:
  An alternate usage/definition syntax for properties.
 
 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP4
 
 Note that there are a few parts marked NEED HELP, that could use assistance 
 from someone with more expertise in this than me.
 
 

A one liner should do the trick too. [public] [const] property int i; public -> delphi published const -> readonly / getter the compiler can generate getter and setter code.
Jul 25 2009
next sibling parent BLS <windevguy hotmail.de> writes:
BLS wrote:
 Nick Sabalausky wrote:
  An alternate usage/definition syntax for properties.

 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP4

 Note that there are a few parts marked NEED HELP, that could use 
 assistance from someone with more expertise in this than me.

A one liner should do the trick too. [public] [const] property int i; public -> delphi published const -> readonly / getter the compiler can generate getter and setter code.

[public] [const|immutable] property int i;
Jul 25 2009
prev sibling next sibling parent reply BLS <windevguy hotmail.de> writes:
BLS wrote:
 Nick Sabalausky wrote:
  An alternate usage/definition syntax for properties.

 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP4

 Note that there are a few parts marked NEED HELP, that could use 
 assistance from someone with more expertise in this than me.

A one liner should do the trick too. [public] [const] property int i; public -> delphi published const -> readonly / getter the compiler can generate getter and setter code.

I am a little bit ''' about the feedback : Is there really nobody who got it : immutable property int i -> becomes : pure int get_i() nothrow { return i } take the rest of the syntax and tell me where the leak is.
Jul 26 2009
next sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
BLS wrote:

 A one liner should do the trick too.
 [public] [const] property int i;

I am a little bit ''' about the feedback : Is there really nobody who got it :

I think people got it. But it's not a property. Your one-liner seems to be equivalent to a field. Except, I guess, that you can't take the address. The whole idea of a property is that it can have non-trivial getter/setter functions. Like a read-only property of a Line, that returns its length automatically calculated from its two points. Or a getter and setter that keep a log of all accesses to the information. My favorite example is of a Color class, that internally stores its value in the RGB model, but has properties to read and change its value through the HSV and HSL models as well. -- Michiel Helvensteijn
Jul 26 2009
parent reply BLS <windevguy hotmail.de> writes:
Michiel Helvensteijn wrote:
 BLS wrote:
 
 A one liner should do the trick too.
 [public] [const] property int i;

Is there really nobody who got it :

I think people got it. But it's not a property. Your one-liner seems to be equivalent to a field. Except, I guess, that you can't take the address. The whole idea of a property is that it can have non-trivial getter/setter functions. Like a read-only property of a Line, that returns its length automatically calculated from its two points. Or a getter and setter that keep a log of all accesses to the information. My favorite example is of a Color class, that internally stores its value in the RGB model, but has properties to read and change its value through the HSV and HSL models as well.

well, the one liner assumes that the compiler will do code generation. (maybe I should figure that out... imutable property uint theAnswer = 42: ====================================== ie. class universe { inmutable property uint theAnswer = 42: /* expands to !! pure uint get_theAnswer() nothrow() { return theAnswer; } private inmutable int theAnswer = 42 */ } and : property bool has_cojones; ========================== class manorweeny { property bool has_cojones; /* expands to !! bool get_has_cojones() { return has_cojones; } void set_has_Cojones(bool yep) { has_cjojones = yep; } private bool has_cojones = false; */ } ---- I just can imagine two property situations : Read + Write OR Read Only... thanks for you feedback Michiel, Björn
Jul 26 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"BLS" <windevguy hotmail.de> wrote in message 
news:h4ilju$1m51$1 digitalmars.com...
 well, the  one liner assumes that the compiler will do code generation. 
 (maybe I should figure that out...


 imutable property uint theAnswer = 42:
 ======================================

 ie.
 class universe
 {

   inmutable property uint theAnswer = 42:

   /* expands to !!

   pure uint get_theAnswer() nothrow()
   {
     return theAnswer;
   }


   private inmutable int theAnswer = 42

   */

 }


 and :

 property bool has_cojones;
 ==========================

 class manorweeny
 {

   property bool has_cojones;

   /* expands to !!

   bool get_has_cojones()
   {
     return has_cojones;
   }

   void set_has_Cojones(bool yep)
   {
     has_cjojones = yep;
   }

   private bool has_cojones = false;
  */

 }

 ---- I just can imagine two property situations :
 Read + Write OR  Read Only...

 thanks for you feedback Michiel,
 Björn

I still don't see how any of that allows any of the things that properties are actually used for (as opposed to just an ordinary variable). Under what you're proposing, how does one actually write their own getter/setter for the property?
Jul 26 2009
prev sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
BLS wrote:

 I think people got it. But it's not a property. Your one-liner seems to
 be equivalent to a field. Except, I guess, that you can't take the
 address.
 
 The whole idea of a property is that it can have non-trivial
 getter/setter functions. Like a read-only property of a Line, that
 returns its length automatically calculated from its two points. Or a
 getter and setter that keep a log of all accesses to the information.
 
 My favorite example is of a Color class, that internally stores its value
 in the RGB model, but has properties to read and change its value through
 the HSV and HSL models as well.

...

Again, what is the difference between your one-liners and simple fields? immutable property uint theAnswer = 42; bool has_cojones; A property is much more sophisticated. The whole point is to write your own setter and getter methods. Only in very few cases do you want a property with simple field semantics. I will give you that Line class I was talking about. Tell me how you can do this with your one-liner: class Line { private: Point _a; Point _b; public: this(Point a, Point b) { _a = a; _b = b; } property float length { auto get() { float absX = abs(_a.x - _b.x); float absY = abs(_a.y - _b.y); return sqrt(absX * absX + absY * absY); } } // insert trivial properties to read/write points } You see, the length property doesn't have its own storage. It deduces its value from the points of the line. -- Michiel Helvensteijn
Jul 27 2009
parent reply BLS <windevguy hotmail.de> writes:
Michiel Helvensteijn wrote:
 BLS wrote:
 
 I think people got it. But it's not a property. Your one-liner seems to
 be equivalent to a field. Except, I guess, that you can't take the
 address.

 The whole idea of a property is that it can have non-trivial
 getter/setter functions. Like a read-only property of a Line, that
 returns its length automatically calculated from its two points. Or a
 getter and setter that keep a log of all accesses to the information.

 My favorite example is of a Color class, that internally stores its value
 in the RGB model, but has properties to read and change its value through
 the HSV and HSL models as well.


Again, what is the difference between your one-liners and simple fields? immutable property uint theAnswer = 42; bool has_cojones; A property is much more sophisticated. The whole point is to write your own setter and getter methods. Only in very few cases do you want a property with simple field semantics. I will give you that Line class I was talking about. Tell me how you can do this with your one-liner: class Line { private: Point _a; Point _b; public: this(Point a, Point b) { _a = a; _b = b; } property float length { auto get() { float absX = abs(_a.x - _b.x); float absY = abs(_a.y - _b.y); return sqrt(absX * absX + absY * absY); } } // insert trivial properties to read/write points } You see, the length property doesn't have its own storage. It deduces its value from the points of the line.

I don't agree . 1- In most cases we have to deal with simple field semantics, No ? x,y,z so : immutable property uint theAnswer = 42; is a getter()...... period. your calculated length property is an exception, should be written in standard D code. IMO a property is a simple thing, a color, a weight, or a mass...
Jul 28 2009
parent reply BLS <windevguy hotmail.de> writes:
Bill Baxter wrote:
 On Tue, Jul 28, 2009 at 3:53 PM, BLS<windevguy hotmail.de> wrote:
 Michiel Helvensteijn wrote:
 BLS wrote:

 I think people got it. But it's not a property. Your one-liner seems to
 be equivalent to a field. Except, I guess, that you can't take the
 address.

 The whole idea of a property is that it can have non-trivial
 getter/setter functions. Like a read-only property of a Line, that
 returns its length automatically calculated from its two points. Or a
 getter and setter that keep a log of all accesses to the information.

 My favorite example is of a Color class, that internally stores its
 value
 in the RGB model, but has properties to read and change its value
 through
 the HSV and HSL models as well.


immutable property uint theAnswer = 42; bool has_cojones; A property is much more sophisticated. The whole point is to write your own setter and getter methods. Only in very few cases do you want a property with simple field semantics. I will give you that Line class I was talking about. Tell me how you can do this with your one-liner: class Line { private: Point _a; Point _b; public: this(Point a, Point b) { _a = a; _b = b; } property float length { auto get() { float absX = abs(_a.x - _b.x); float absY = abs(_a.y - _b.y); return sqrt(absX * absX + absY * absY); } } // insert trivial properties to read/write points } You see, the length property doesn't have its own storage. It deduces its value from the points of the line.

1- In most cases we have to deal with simple field semantics, No ? x,y,z so : immutable property uint theAnswer = 42; is a getter()...... period. your calculated length property is an exception, should be written in standard D code. IMO a property is a simple thing, a color, a weight, or a mass...

How is length not as simple as a color? I don't get it. And consider the case of complex numbers. Either the pair (real,imag) is stored or (modulus,argument) is stored. Neither is more "fundamental" than the other as a representation. Which one do you make a field and which one "standard D code"? --bb

hi bill, my fault, I mean distance.. (instead of length) Hope you agree with me that a colour (in the senses of E. Kant ) is something we can'T see as it is. but we gave and give it nevertheless a name : likewise red. Does not mean too much just :RED is a propetry. Now let`s compare that with distance calculation (without drifting too much away) RED is a property, Distance means necessarily a calculation. The question is ergo : Do we want pure behavior or math in our properties. IMO, behavior. This is what property means. so imutable proberty bool killbillv2 = false // is a read only getter .. (However to answer : ref... delegate and you have everything you need)
Jul 28 2009
parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
BLS wrote:
 Bill Baxter wrote:
 How is length not as simple as a color?  I don't get it.

 And consider the case of complex numbers.  Either the pair (real,imag)
 is stored or (modulus,argument) is stored.  Neither is more
 "fundamental" than the other as a representation.  Which one do you
 make a field and which one "standard D code"?

 --bb

hi bill, my fault, I mean distance.. (instead of length) Hope you agree with me that a colour (in the senses of E. Kant ) is something we can'T see as it is. but we gave and give it nevertheless a name : likewise red. Does not mean too much just :RED is a propetry. Now let`s compare that with distance calculation (without drifting too much away) RED is a property, Distance means necessarily a calculation. The question is ergo : Do we want pure behavior or math in our properties. IMO, behavior. This is what property means. so imutable proberty bool killbillv2 = false // is a read only getter .. (However to answer : ref... delegate and you have everything you need)

RED is a calculation if your color is stored in HSV space (or LAB space or CMYK, or...). In this case I'm assuming you are trying to retrieve the red content of a color. Otherwise if RED is some kind of constant, then it is stored in SOME representation. Then whenever you see "color = RED;" there MAY be a representation conversion depending on how the variable/property color does its storage internally. There are many numbers that exist without actually being stored anywhere. They are pretty useful to exploit since they require no memory ;)
Jul 29 2009
prev sibling parent Rainer Deyke <rainerd eldwood.com> writes:
BLS wrote:
 immutable property int i -> becomes :
 
 pure int get_i() nothrow
 {
  return i
 }

I can't figure out the semantics of this. Is 'i' a property, a variable, or both? If it's both, how do you syntactically distinguish between them? -- Rainer Deyke - rainerd eldwood.com
Jul 26 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, Jul 28, 2009 at 3:53 PM, BLS<windevguy hotmail.de> wrote:
 Michiel Helvensteijn wrote:
 BLS wrote:

 I think people got it. But it's not a property. Your one-liner seems t=




 be equivalent to a field. Except, I guess, that you can't take the
 address.

 The whole idea of a property is that it can have non-trivial
 getter/setter functions. Like a read-only property of a Line, that
 returns its length automatically calculated from its two points. Or a
 getter and setter that keep a log of all accesses to the information.

 My favorite example is of a Color class, that internally stores its
 value
 in the RGB model, but has properties to read and change its value
 through
 the HSV and HSL models as well.

...

Again, what is the difference between your one-liners and simple fields? immutable property uint theAnswer =3D 42; bool has_cojones; A property is much more sophisticated. The whole point is to write your own setter and getter methods. Only in very few cases do you want a property with simple field semantics. I will give you that Line class I was talki=


 about. Tell me how you can do this with your one-liner:

 class Line {
 =A0 =A0private:
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Point _a;
 =A0 =A0 =A0 =A0Point _b;
 =A0 =A0 =A0 =A0public:
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0this(Point a, Point b) { _a =3D a; _b =3D=


 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0property float length {
 =A0 =A0 =A0 =A0 =A0 =A0auto get() {
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0float absX =3D abs(_a.x - _b.x);
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0float absY =3D abs(_a.y - _b.y);
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return sqrt(absX * absX + absY * absY);
 =A0 =A0 =A0 =A0 =A0 =A0}
 =A0 =A0 =A0 =A0}
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// insert trivial properties to read/writ=


 }

 You see, the length property doesn't have its own storage. It deduces it=


 value from the points of the line.

I don't agree . 1- In most cases we have to deal with simple field semantics, No ? x,y,z so : immutable property uint theAnswer =3D 42; is a getter()...... period=

 your calculated length property is an exception, should be written in
 standard D code.

 IMO a property is a simple thing, a color, a weight, or a mass...

How is length not as simple as a color? I don't get it. And consider the case of complex numbers. Either the pair (real,imag) is stored or (modulus,argument) is stored. Neither is more "fundamental" than the other as a representation. Which one do you make a field and which one "standard D code"? --bb
Jul 28 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Nick Sabalausky, el 24 de julio a las 00:39 me escribiste:
  An alternate usage/definition syntax for properties.
 
 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP4
 
 Note that there are a few parts marked NEED HELP, that could use assistance 
 from someone with more expertise in this than me.

After reading all the threads again, I think the best proposal is the opGet_foo() / opSet_foo() for diferentiating functions and properties. I think is the more D-ish solution. I don't like the "_name" though, because it adds semantic infomation to the identifier, maybe a more template-like syntax can be used: class X { private int _foo; public string _bar; long opGet(baz)() { return _foo + _bar.lenght; } void opSet(baz)(int x) { assert(x >= _bar.lenght); _foo = x - _bar.lenght; } void f() { auto b = baz; // opGet(baz)() b += 10; baz = b; // opSet(baz)() } } I used an example without trivial properties because... well, you just use member variables for that. That's why I don't see real value in adding default properties getter/setters. I don't see DRY as a real problem either, for non-trivial properties. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- EL PRIMER MONITO DEL MILENIO... -- Crónica TV
Jul 25 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Leandro Lucarella wrote:
 Nick Sabalausky, el 24 de julio a las 00:39 me escribiste:
  An alternate usage/definition syntax for properties.

 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP4

 Note that there are a few parts marked NEED HELP, that could use assistance 
 from someone with more expertise in this than me.

After reading all the threads again, I think the best proposal is the opGet_foo() / opSet_foo() for diferentiating functions and properties. I think is the more D-ish solution. I don't like the "_name" though, because it adds semantic infomation to the identifier, maybe a more template-like syntax can be used:

That would involve changing template syntax to allow for identifiers to be passed as an argument. Besides, templates can't be used as virtual methods, so they can't be overridden and can't appear in interfaces.
 ...
 
 I used an example without trivial properties because... well, you just use
 member variables for that. That's why I don't see real value in adding
 default properties getter/setters.

interface I { int opGet_value(); } You cannot use fields in an interface.
Jul 26 2009
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Daniel Keep, el 27 de julio a las 01:09 me escribiste:
 
 
 Leandro Lucarella wrote:
 Nick Sabalausky, el 24 de julio a las 00:39 me escribiste:
  An alternate usage/definition syntax for properties.

 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP4

 Note that there are a few parts marked NEED HELP, that could use assistance 
 from someone with more expertise in this than me.

After reading all the threads again, I think the best proposal is the opGet_foo() / opSet_foo() for diferentiating functions and properties. I think is the more D-ish solution. I don't like the "_name" though, because it adds semantic infomation to the identifier, maybe a more template-like syntax can be used:

That would involve changing template syntax to allow for identifiers to be passed as an argument. Besides, templates can't be used as virtual methods, so they can't be overridden and can't appear in interfaces.

Syntax don't have to be changed, unless templates are not allowed (syntactically) in interfaces (I'm too lazy to check right now :). And template syntax don't have to change either. This is already valid AFAIK syntax AFAIK. What it has to be changed, is the semantics, because int opGet(foo)(); should be interpreted as a read property instead of a templated function.
 ...
 
 I used an example without trivial properties because... well, you just use
 member variables for that. That's why I don't see real value in adding
 default properties getter/setters.

interface I { int opGet_value(); } You cannot use fields in an interface.

Yes, and...? -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- There is no such thing as right or wrong Only consequences
Jul 26 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Leandro Lucarella wrote:
 Daniel Keep, el 27 de julio a las 01:09 me escribiste:
 Leandro Lucarella wrote:
 Nick Sabalausky, el 24 de julio a las 00:39 me escribiste:
  An alternate usage/definition syntax for properties.

 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP4

 Note that there are a few parts marked NEED HELP, that could use assistance 
 from someone with more expertise in this than me.

opGet_foo() / opSet_foo() for diferentiating functions and properties. I think is the more D-ish solution. I don't like the "_name" though, because it adds semantic infomation to the identifier, maybe a more template-like syntax can be used:

be passed as an argument. Besides, templates can't be used as virtual methods, so they can't be overridden and can't appear in interfaces.

Syntax don't have to be changed, unless templates are not allowed (syntactically) in interfaces (I'm too lazy to check right now :). And template syntax don't have to change either. This is already valid AFAIK syntax AFAIK. What it has to be changed, is the semantics, because int opGet(foo)(); should be interpreted as a read property instead of a templated function.

Ok, I should have said "semantics" instead of syntax. The thing is you're proposing that template syntax doesn't *actually* mean a template if the identifier is "opGet". opGet effectively becomes a keyword; so you may as well just bite the bullet and add "property" as a keyword.
 ...

 I used an example without trivial properties because... well, you just use
 member variables for that. That's why I don't see real value in adding
 default properties getter/setters.

{ int opGet_value(); } You cannot use fields in an interface.

Yes, and...?

You have an interface. One of the things it needs to do is provide access to a field. You can't just declare a field; you have to have an accessor. In most situations, the implementation will simply want to expose some internal field.
Jul 26 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Daniel Keep, el 27 de julio a las 02:29 me escribiste:
 Syntax don't have to be changed, unless templates are not allowed
 (syntactically) in interfaces (I'm too lazy to check right now :).
 
 And template syntax don't have to change either. This is already valid
 AFAIK syntax AFAIK. What it has to be changed, is the semantics, because
 int opGet(foo)(); should be interpreted as a read property instead of
 a templated function.

Ok, I should have said "semantics" instead of syntax. The thing is you're proposing that template syntax doesn't *actually* mean a template if the identifier is "opGet". opGet effectively becomes a keyword; so you may as well just bite the bullet and add "property" as a keyword.

Why it is a keyword? I know is a little controversial to change the meaning of template syntax based on the function name (and I think that's a good point for dismissing my proposal) but I really don't get why do you think that it's like adding a keyword. You don't have to make opGet a reserved word, you could use a variable named opGet if you want, the same you can use opCall or the other "magical" method names. I'm not really sure what is worse from a philosophical POV, if changing the template syntax meaning for opGet (opGet(prop)) or extract semantic information from a method name (opGet_prop). I think that the former looks a little cleaner at least =)
 I used an example without trivial properties because... well, you just use
 member variables for that. That's why I don't see real value in adding
 default properties getter/setters.

{ int opGet_value(); } You cannot use fields in an interface.

Yes, and...?

You have an interface. One of the things it needs to do is provide access to a field. You can't just declare a field; you have to have an accessor. In most situations, the implementation will simply want to expose some internal field.

So, you think there should be an easy way to define default getter/setters? If that's what you're saying, I didn't saw how that is handled in your proposal, I'm sorry, I'll take a look again. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Un camión lleno de amigos, míos. Cada uno dando vueltas, en su cabeza. Mientras yo, sufro la picadura de mi propia abeja.
Jul 26 2009
prev sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Daniel Keep wrote:

 I used an example without trivial properties because... well, you just
 use member variables for that. That's why I don't see real value in
 adding default properties getter/setters.

interface I { int opGet_value(); } You cannot use fields in an interface.

You do understand that properties with automatic backing storage would probably also not be allowed in interfaces. They'd have the same memory layout problems as fields. -- Michiel Helvensteijn
Jul 26 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Michiel Helvensteijn wrote:
 Daniel Keep wrote:
 
 I used an example without trivial properties because... well, you just
 use member variables for that. That's why I don't see real value in
 adding default properties getter/setters.

{ int opGet_value(); } You cannot use fields in an interface.

You do understand that properties with automatic backing storage would probably also not be allowed in interfaces. They'd have the same memory layout problems as fields.

*blink* You wouldn't declare a property with automatic backing in an interface; that would be specifying implementation which you're not allowed to do. I was demonstrating why trivial properties exist in real code. It's the *class* that would declare a property with automatic storage.
Jul 26 2009
parent Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Daniel Keep wrote:

 You do understand that properties with automatic backing storage would
 probably also not be allowed in interfaces. They'd have the same memory
 layout problems as fields.

*blink*

*blink*
 You wouldn't declare a property with automatic backing in an interface;
 that would be specifying implementation which you're not allowed to do.
 
 I was demonstrating why trivial properties exist in real code.  It's the
 *class* that would declare a property with automatic storage.

Ah, you're talking about the interface to a property, not the property itself. I see what you mean now. My mistake. -- Michiel Helvensteijn
Jul 26 2009