• Ant (6/6) Apr 26 2004 What is the real benefit of class and struct properties?
• Ben Hinkle (12/18) Apr 26 2004 "Real" is up to you, but some benefits are:
• Ant (15/28) Apr 26 2004 so is just the "expressiveness" thing as Juan said.
• Hauke Duden (24/47) Apr 26 2004 It gets really nice if you want to get and set in the same expression:
• Ant (10/31) Apr 26 2004 good examples.
• C. Sauls (29/38) Apr 26 2004 I and a couple of the C#-using people have been asking for that... I'd
• Derek Parnell (6/52) Apr 26 2004 Oh that *is* nice. Very clean and very readable. Solves some 'naming
• Ivan Senji (8/55) Apr 26 2004 (eg.
• Juan C (1/2) Apr 26 2004 It's an "expressiveness" thing.
• Ant (3/5) Apr 26 2004 I see...
• Achilleas Margaritis (4/10) Apr 27 2004 It is also easier to document: you just say class Foo has property Bar a...
• J Anderson (7/13) Apr 27 2004 I had to speak up. I like it the way things are. I think if there's

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

"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

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

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

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

"C. Sauls" <ibisbasenji yahoo.com> writes:

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;};
 };

Derek Parnell <derek psych.ward> writes:

On Mon, 26 Apr 2004 15:57:36 -0500, C. Sauls wrote:



 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

"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



(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)

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

Juan C <Juan_member pathlink.com> writes:

What is the real benefit of class and struct properties?

It's an "expressiveness" thing.

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

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.

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/