www.digitalmars.com         C & C++   DMDScript  

D - [Q] What is the real benefit of class and struct properties?

reply Ant <Ant_member pathlink.com> writes:
What is the real benefit of class and struct properties?

I dont' see any!...
Anyone can help me?

should I make an effored to implement then on leds intellisense?

thanks,
Ant
Apr 26 2004
next sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:c6jcf0$g74$1 digitaldaemon.com...
 What is the real benefit of class and struct properties?

"Real" is up to you, but some benefits are: - they let you compute "fields" on the fly instead of storing them in memory. - they provide getter/setter functions to pass to generic functions or algorithms - they save on typing () to call a function Basically the upside is flexibility. The downside is in user code "a.b" looks like a field reference but if might not execute in constant time (eg. the length property of assoc arrays is linear in the number of elements in the array).
 I dont' see any!...
 Anyone can help me?

 should I make an effored to implement then on leds intellisense?

 thanks,
 Ant

Apr 26 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <c6jjii$ssf$1 digitaldaemon.com>, Ben Hinkle says...
"Ant" <Ant_member pathlink.com> wrote in message
news:c6jcf0$g74$1 digitaldaemon.com...
 What is the real benefit of class and struct properties?

"Real" is up to you, but some benefits are: - they let you compute "fields" on the fly instead of storing them in memory. - they provide getter/setter functions to pass to generic functions or algorithms

Yes, I meant as opposed to the getter and setter... sorry.
- they save on typing () to call a function

Basically the upside is flexibility. The downside is in user code "a.b"
looks like a field reference but if might not execute in constant time (eg.
the length property of assoc arrays is linear in the number of elements in
the array).

so is just the "expressiveness" thing as Juan said. I don't think the trick is how much you save typing but how much you save reading. maybe it's good: hat.setColor(green); hat.color = green; if ( hat.getColor() == red ) if ( hat.color == red ) definitively ( hat.color == red ) reads better then ( hat.getColor() == red ) my problem is exactly what you stated as the downside. Maybe I'll try to use it. (it's going to be a mess on the transitional programs...) Ant
Apr 26 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Ant wrote:
Basically the upside is flexibility. The downside is in user code "a.b"
looks like a field reference but if might not execute in constant time (eg.
the length property of assoc arrays is linear in the number of elements in
the array).

so is just the "expressiveness" thing as Juan said. I don't think the trick is how much you save typing but how much you save reading. maybe it's good: hat.setColor(green); hat.color = green; if ( hat.getColor() == red ) if ( hat.color == red ) definitively ( hat.color == red ) reads better then ( hat.getColor() == red )

It gets really nice if you want to get and set in the same expression: fun.amount += 3; as opposed to fun.setAmount( fun.getAmount() + 3);
 my problem is exactly what you stated as the downside.
 Maybe I'll try to use it.
 (it's going to be a mess on the transitional programs...)

I'm not so much concerned with the execution speed. You have the same problem when you use get methods. The really bad stuff is when this feature is abused and an expression that looks like it simply reads a field is actually modifying the object. This can cause code to become very hard to read. For example, if x is an iterator of some kind and "next" advances the iterator and returns the current object it points to, then you should definitely not write: a=x.next; but instead a=x.next(); I would prefer if there was some mechanism in the language to prevent the property syntax to be used with normal methods. That would make this kind of readability nightmare impossible. I think property methods should be explicitly marked as such, and only property methods should be callable without (). Maybe something like this: prop int amount() prop void amount(int) Hauke
Apr 26 2004
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <c6jntt$14kg$1 digitaldaemon.com>, Hauke Duden says...
Ant wrote:

It gets really nice if you want to get and set in the same expression:

fun.amount += 3;

as opposed to

fun.setAmount( fun.getAmount() + 3);

The really bad stuff is when this feature is abused and an expression 
that looks like it simply reads a field is actually modifying the 
object. This can cause code to become very hard to read.

For example, if x is an iterator of some kind and "next" advances the 
iterator and returns the current object it points to, then you should 
definitely not write:

a=x.next;

but instead

a=x.next();

I would prefer if there was some mechanism in the language to prevent 
the property syntax to be used with normal methods. That would make this 
kind of readability nightmare impossible.
I think property methods should be explicitly marked as such, and only 
property methods should be callable without (). Maybe something like this:

prop int amount()
prop void amount(int)

good examples. the prop keyword would be a nice and simple way to do it. I remember seeing (here?) something like: prop int amount { get(){return amount;}; set(int amount){ this.amount = amount;}; }; Ant
Apr 26 2004
parent reply "C. Sauls" <ibisbasenji yahoo.com> writes:
I and a couple of the C#-using people have been asking for that...  I'd
prefer Lux-style (the way you quoted it) over the C# style though.
Which would turn:

<code>
// property: foo
int _foo;
// get
int foo() { return _foo; }
// set
void foo(int x)    { _foo = x; }
void foo(char[] x) { _foo = toInt(x); }
void foo(double x) { _foo = cast(int) (x + 0.5); }
</code>

into:

<code>
property int foo {
   int get() { return foo; }

   void set(int x)    { foo = x; }
   void set(char[] x) { foo = toInt(x); }
   void set(double x) { foo = cast(int) (x + 0.5); }
}
</code>

I think its cleaner, more compileable (in theory... never written a
compiler, so I may not know), and certainly lends itself more to
self-documenting code.

-C. Sauls
-Invironz

[Edited to fix a silly typo.]

Ant wrote:
 the prop keyword would be a nice and simple way to do it.
 
 I remember seeing (here?) something like:
 
 prop int amount
 {
   get(){return amount;};
   set(int amount){ this.amount = amount;};
 };

Apr 26 2004
parent Derek Parnell <derek psych.ward> writes:
On Mon, 26 Apr 2004 15:57:36 -0500, C. Sauls wrote:

 I and a couple of the C#-using people have been asking for that...  I'd
 prefer Lux-style (the way you quoted it) over the C# style though.
 Which would turn:
 
 <code>
 // property: foo
 int _foo;
 // get
 int foo() { return _foo; }
 // set
 void foo(int x)    { _foo = x; }
 void foo(char[] x) { _foo = toInt(x); }
 void foo(double x) { _foo = cast(int) (x + 0.5); }
 </code>
 
 into:
 
 <code>
 property int foo {
    int get() { return foo; }
 
    void set(int x)    { foo = x; }
    void set(char[] x) { foo = toInt(x); }
    void set(double x) { foo = cast(int) (x + 0.5); }
 }
 </code>
 
 I think its cleaner, more compileable (in theory... never written a
 compiler, so I may not know), and certainly lends itself more to
 self-documenting code.
 
 -C. Sauls
 -Invironz
 
 [Edited to fix a silly typo.]
 
 Ant wrote:
 the prop keyword would be a nice and simple way to do it.
 
 I remember seeing (here?) something like:
 
 prop int amount
 {
   get(){return amount;};
   set(int amount){ this.amount = amount;};
 };


Oh that *is* nice. Very clean and very readable. Solves some 'naming conventions' too. -- Derek 27/Apr/04 9:47:36 AM
Apr 26 2004
prev sibling parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:c6jntt$14kg$1 digitaldaemon.com...
 Ant wrote:
Basically the upside is flexibility. The downside is in user code "a.b"
looks like a field reference but if might not execute in constant time



the length property of assoc arrays is linear in the number of elements



the array).

so is just the "expressiveness" thing as Juan said. I don't think the trick is how much you save typing but how much you save reading. maybe it's good: hat.setColor(green); hat.color = green; if ( hat.getColor() == red ) if ( hat.color == red ) definitively ( hat.color == red ) reads better then ( hat.getColor() ==


 It gets really nice if you want to get and set in the same expression:

 fun.amount += 3;

 as opposed to

 fun.setAmount( fun.getAmount() + 3);

 my problem is exactly what you stated as the downside.
 Maybe I'll try to use it.
 (it's going to be a mess on the transitional programs...)

I'm not so much concerned with the execution speed. You have the same problem when you use get methods. The really bad stuff is when this feature is abused and an expression that looks like it simply reads a field is actually modifying the object. This can cause code to become very hard to read. For example, if x is an iterator of some kind and "next" advances the iterator and returns the current object it points to, then you should definitely not write: a=x.next; but instead a=x.next(); I would prefer if there was some mechanism in the language to prevent the property syntax to be used with normal methods. That would make this kind of readability nightmare impossible. I think property methods should be explicitly marked as such, and only property methods should be callable without (). Maybe something like this: prop int amount() prop void amount(int)

This would really be great. Properties are great and this would solve the only problem they have: calling a nonproperty method in a property way.
 Hauke

Apr 26 2004
prev sibling next sibling parent reply Juan C <Juan_member pathlink.com> writes:
What is the real benefit of class and struct properties?

It's an "expressiveness" thing.
Apr 26 2004
parent Ant <Ant_member pathlink.com> writes:
In article <c6jkns$v83$1 digitaldaemon.com>, Juan C says...
What is the real benefit of class and struct properties?

It's an "expressiveness" thing.

I see... Ant
Apr 26 2004
prev sibling next sibling parent Achilleas Margaritis <Achilleas_member pathlink.com> writes:
In article <c6jcf0$g74$1 digitaldaemon.com>, Ant says...
What is the real benefit of class and struct properties?

I dont' see any!...
Anyone can help me?

should I make an effored to implement then on leds intellisense?

thanks,
Ant

It is also easier to document: you just say class Foo has property Bar and the programmer knows that he can get the value of bar with foo.bar and set it with foo.bar.
Apr 27 2004
prev sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
Ant wrote:

What is the real benefit of class and struct properties?

I dont' see any!...
Anyone can help me?

should I make an effored to implement then on leds intellisense?

thanks,
Ant

I had to speak up. I like it the way things are. I think if there's going to be anything, it should be an opt out rather then an opt in. That is something like: method void value(int val) { ... } -- -Anderson: http://badmama.com.au/~anderson/
Apr 27 2004