class Abc   {
      int myprop;
      void property(int newproperty) { myprop = newproperty; } // set'er
      int property() { return myprop; }// get'er
      }

Isn't this syntax horribly redundant?

Doesn't

   class Abc   {
      int <property> myprop;
      }

carry just as much meaning?  The compiler can generate default gets and sets, and allow user-defined ones as well.

   class Abc  {
       int <property> myprop;
       void myprop ( Error ("Can't set myprop!") );
      }

This provides clarity, saves a lot of typing, and (I would guess) is
easy to implement.

Karl Bochert

"Karl Bochert" <kbochert@ix.netcom.com> wrote in message news:1103_1021740941@bose...

> Doesn't
>
>    class Abc   {
>       int <property> myprop;
>       }
>
> carry just as much meaning?  The compiler can generate default gets and sets, and allow user-defined ones as well.

No, because it doesn't allow for compile-time read-only (and write-only)
properties.

>    class Abc  {
>        int <property> myprop;
>        void myprop ( Error ("Can't set myprop!") );
>       }
>
> This provides clarity, saves a lot of typing, and (I would guess) is
> easy to implement.

Clarity, maybe. But I don't care much of it, personally. As long as one groups property gettors and settors together, they are easy to spot.

A lot of typing? Note, you had to define one function to define the property as read-only. Currently, you'd just define a single gettor. The same goes for write-only properties. And if it's read/write, you'll have to define 2 functions + 1 line which declares the property itself...

On Sat, 18 May 2002 21:07:22 +0400, "Pavel Minayev" <evilone@omen.ru> wrote:
> "Karl Bochert" <kbochert@ix.netcom.com> wrote in message news:1103_1021740941@bose...
> 
> > Doesn't
> >
> >    class Abc   {
> >       int <property> myprop;
> >       }
> >
> > carry just as much meaning?  The compiler can generate default gets and sets, and allow user-defined ones as well.
> 
> No, because it doesn't allow for compile-time read-only (and write-only)
> properties.
>

Surely it is better to have the read-only-ness expressed in the declaration than in the presence or absence of a specific function, somewhere in multiple pages of code!

> >    class Abc  {
> >        int <property> myprop;
> >        void myprop ( Error ("Can't set myprop!") );
> >       }
> >
> > This provides clarity, saves a lot of typing, and (I would guess) is
> > easy to implement.
> 
> Clarity, maybe. But I don't care much of it, personally. As long as one groups property gettors and settors together, they are easy to spot.
>

Of course they also move more interesting code to the next page.

> A lot of typing? Note, you had to define one function to define the property as read-only. Currently, you'd just define a single gettor. The same goes for write-only properties. And if it's read/write, you'll have to define 2 functions + 1 line which declares the property itself...
> 

I was looking at the example give in the manual, where a justification
for the current syntax was that it reduced typing (from 111 characters
to 99) as compared to C.  This syntax reduces the example to 22, at
no loss of clarity.  Of course the issue is not typing, but the presence
of 'typographic noise'.


Karl

Err, hm

Basically what http://www.digitalmars.com/d/class.html is saying is to use

class Abc
{
      int property;
}

Until you need to cater for special cases then put the getters and setters on, which is one word less then your <property> method.

PS -
It'd be nice though, if a resulting D IDE, could auto generate geter and
seter code (when it was needed) or even better support UML.


"Karl Bochert" <kbochert@ix.netcom.com> wrote in message news:1103_1021740941@bose...
>
>    class Abc   {
>       int myprop;
>       void property(int newproperty) { myprop = newproperty; } // set'er
>       int property() { return myprop; }// get'er
>       }
>
> Isn't this syntax horribly redundant?
>
> Doesn't
>
>    class Abc   {
>       int <property> myprop;
>       }
>
> carry just as much meaning?  The compiler can generate default gets and sets, and allow user-defined ones as well.
>
>    class Abc  {
>        int <property> myprop;
>        void myprop ( Error ("Can't set myprop!") );
>       }
>
> This provides clarity, saves a lot of typing, and (I would guess) is
> easy to implement.
>
> Karl Bochert
>
>
>
>

So are all instance variables considered public by default then?
-Jon

anderson wrote:

> Err, hm
> 
> Basically what http://www.digitalmars.com/d/class.html is saying is to use
> 
> class Abc
> {
>       int property;
> }
> 
> 

That'd be my guess to since much of the sample code at http://www.digitalmars.com is represented that way.  After I had added my get and set functions I'd move the variable into protected or private space.


"Jonathan Andrew" <jon@ece.arizona.edu> wrote in message news:3CE7E24B.5040209@ece.arizona.edu...
> So are all instance variables considered public by default then? -Jon
>
> anderson wrote:
>
> > Err, hm
> >
> > Basically what http://www.digitalmars.com/d/class.html is saying is to
use
> >
> > class Abc
> > {
> >       int property;
> > }
> >
> >
>
>

In article <ac7h7t$8il$1@digitaldaemon.com>, anderson says...
>
>Err, hm
>
>Basically what http://www.digitalmars.com/d/class.html is saying is to use
>
>>> .....

Properties work fine for RAD aproach, make code more clear, an u can make
properties read,read/write, public, private...and more.
To day language not is only a compiler is more than that, we need tools
(builder, RADs, and more).

One example, if you wan't make Enterprice JavaBeans you nead emulate properties in the program, in the IDE or Builder and in the interface, so are to bad properties?