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

"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

>What is the real benefit of class and struct properties?

It's an "expressiveness" thing.

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

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

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

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

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

"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

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