I have 6 years experience in c++ and also in some other languages, but never used a language which has object "properties". (like my_array.length = 10 automagically resizing the array) Can someone guide me to a tutorial about properties? What are they good for, how they are defined and used, why are they better then other alternative concepts, like my_array.resize(10).

Yours,
Sandor Hojtsy

Sandor Hojtsy wrote:

> I have 6 years experience in c++ and also in some other languages, but never used a language which has object "properties". (like my_array.length = 10 automagically resizing the array) Can someone guide me to a tutorial about properties? What are they good for, how they are defined and used, why are they better then other alternative concepts, like my_array.resize(10).

I don't have a tutorial, but I have opinions! (grin)

Properties are good because they map variable-type syntax to functions.  In C++ (and Java, I believe), the variable-type and function-type members are totally different parts of the "class interface space."  That means that if you start with a variable named "foo" and write a lot of code that uses that variable directly, it's hard to convert to a gettor/settor syntax:

    MyClass obj;
    obj.foo = 3;
    int var = obj.foo;

    Has to be converted to:

    MyClass obj;
    obj.SetFoo(3);
    int var = obj.GetFoo();

It quickly becomes impractical to change foo from variable to function (or vice-versa) if there is a lot of code.  Some coders anticipate this problem ahead of time, and define Get/Set functions for even the most trivial variables, and the result is that most Get/Set functions never do anything more than just the trivial operation.  This makes the class more complex, and makes the code harder to read.  Other people get tired of defining Get/Set functions and just use variables...then often get bitten later.  I tend to be in the latter camp.

However, with properties, you move variables into the function space.  You can start with a simple class that declares a variable, and write all your code that way.  Later, if you need more smarts in your gettor or settor, you define a property for that, and none of the calling code has to change.  That, IMHO, is a Good Thing.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:abqu10$hir$1@digitaldaemon.com...
> I have 6 years experience in c++ and also in some other languages, but
never
> used a language which has object "properties". (like my_array.length = 10 automagically resizing the array) Can someone guide me to a tutorial about

This is not a very good example of property. The .length property is
built-in...
why not resize()? Because you can both set AND query it. So:

    for (int i = 0; i < array.length; i++)
        ...

Here we query it. As you've pointed out, one can also modify its value, which practically resizes an array. But you don't care how it works - you shouldn't even care if something is done behind the scene, like relocation of the memory block. You treat the "length" as a _property_ of an array, which can be changed if necessary.

The same applies to user-defined properties (of classes). Suppose you have a Button class (from WinD), and you want to change its caption. Traditional C++ approach would be to write a pair of methods for this:

    private char[] caption;
    char[] getCaption() { return caption; }
    void setCaption(char[] s) { caption = s; redraw(); }
    ...
    button.setCaption(toupper(button.GetCaption()) ~ " - CLICKED");

We have to redraw the button if text changes, otherwise we could as well just declare a single "caption" member variable, and now we have to deal with functions... but why should the user of our class be aware of the fact that caption can't be "just changed", like he changes value of the variable? It's an implementation detail, it is supposed to be hidden - but no way to do so...

D provides a workaround for this: you just provide a pair of functions with the same name; this name becomes the name of the property:

    private char[] m_caption;
    char[] caption() { return m_caption; }      // gettor
    void caption(char[] s) { m_caption = s; }   // settor

Now you can write something like:

    button.caption = toupper(button.caption) ~ " - CLICKED";

A lot cleaner, no? One just treats "caption" as a variable - it can be assigned a value, or it can be queried, all using common and clean syntax...

Yes, I understand the benefits when converting from variable to property.
And also when declaring non-modifyable properties (I suppose you can choose
not to define a settor). But there are several properties in D that never
were variables, so I think they will be clearer with explicit get/set.
 I have a feeling that the property concept is overused here: shouldn't
"array.sort" be array.sort() ? It changes the original array. Why do you
need variable syntax here? Do you say array.sort = anotherArray ?
I think the variable syntax should only be used with things obeying some
rules which one associates with variables. Such as reading it does not have
any user-visible side effects. I understand that a compiler cannot guarantee
this, but the built-in properties should be such at least.

If I write (suppose my_prop is integer property):
int a = my_object.my_prop;
my_object.my_prop = a;
It may even come out with changed my_prop, or any other field changed, or
big run-time cost depending on the implementation of my_prop. This is the
opposite of what this (silly) code fragment makes me think. Whereas an
explicit gettor/settor instantly suggests me to check the definition of
those functions in order to ensure that this code fragment is correct. It
helps debugging.

Sandor

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CE10C76.8B74C1CB@deming-os.org...
> Properties are good because they map variable-type syntax to functions.
In C++
> (and Java, I believe), the variable-type and function-type members are
totally
> different parts of the "class interface space."  That means that if you
start
> with a variable named "foo" and write a lot of code that uses that
variable
> directly, it's hard to convert to a gettor/settor syntax:
>
>     MyClass obj;
>     obj.foo = 3;
>     int var = obj.foo;
>
>     Has to be converted to:
>
>     MyClass obj;
>     obj.SetFoo(3);
>     int var = obj.GetFoo();
>
> It quickly becomes impractical to change foo from variable to function (or vice-versa) if there is a lot of code.  Some coders anticipate this
problem
> ahead of time, and define Get/Set functions for even the most trivial
variables,
> and the result is that most Get/Set functions never do anything more than
just
> the trivial operation.  This makes the class more complex, and makes the
code
> harder to read.  Other people get tired of defining Get/Set functions and
just
> use variables...then often get bitten later.  I tend to be in the latter
camp.
>
> However, with properties, you move variables into the function space.  You
can
> start with a simple class that declares a variable, and write all your
code that
> way.  Later, if you need more smarts in your gettor or settor, you define
a
> property for that, and none of the calling code has to change.  That,
IMHO, is a
> Good Thing.

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:abrcjt$tu1$1@digitaldaemon.com...

>  I have a feeling that the property concept is overused here: shouldn't
> "array.sort" be array.sort() ? It changes the original array. Why do you

I agree with you here. It is a procedure, probably: it doesn't take
arguments,
nor does it return value; so, it should be called.

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:abrcjt$tu1$1@digitaldaemon.com...
> Yes, I understand the benefits when converting from variable to property. And also when declaring non-modifyable properties (I suppose you can
choose
> not to define a settor). But there are several properties in D that never
> were variables, so I think they will be clearer with explicit get/set.
>  I have a feeling that the property concept is overused here: shouldn't
> "array.sort" be array.sort() ? It changes the original array. Why do you
> need variable syntax here? Do you say array.sort = anotherArray ?
> I think the variable syntax should only be used with things obeying some
> rules which one associates with variables. Such as reading it does not
have
> any user-visible side effects. I understand that a compiler cannot
guarantee
> this, but the built-in properties should be such at least.

I agree with you that .sort is a bit inconsistent.

>
> Now you can write something like:
>
>     button.caption = toupper(button.caption) ~ " - CLICKED";
>
> A lot cleaner, no? One just treats "caption" as a variable - it can be assigned a value, or it can be queried, all using common and clean syntax...
>
>

I've worked with properties in VB and I like them. But now that you put them
like this, aren't properties like public variables?
If it's so, wouldn't they be against information hiding? If it's not, what's
the difference?

Thanks

"Carlos" <carlos8294@msn.com> wrote in message news:abshai$1rgn$1@digitaldaemon.com...

> I've worked with properties in VB and I like them. But now that you put
them
> like this, aren't properties like public variables?

They are, to the user of the class. That's exactly the idea.
BTW properties can be protected or private. I even think,
the gettor could be public, and the settor could be private...

> If it's so, wouldn't they be against information hiding? If it's not,
what's
> the difference?

I don't understand... the very idea of properties is to hide (encapsulate)
class functionality...

"Pavel Minayev" <evilone@omen.ru> escribió en el mensaje news:absko8$1tut$1@digitaldaemon.com...
> "Carlos" <carlos8294@msn.com> wrote in message news:abshai$1rgn$1@digitaldaemon.com...
>
> > I've worked with properties in VB and I like them. But now that you put
> them
> > like this, aren't properties like public variables?
>
> They are, to the user of the class. That's exactly the idea.
> BTW properties can be protected or private. I even think,
> the gettor could be public, and the settor could be private...
>
> > If it's so, wouldn't they be against information hiding? If it's not,
> what's
> > the difference?
>
> I don't understand... the very idea of properties is to hide (encapsulate)
> class functionality...
>
>
I can kill two birds with one shoot.
Probably I'm too down in OOP theory, but here's the thing: there're some
principles about OOP which are: encapsulate, hide, inheritance, polimorfism,
etc. When I say "hide" I mean "hide data to the user", not only
funcionality. To do this, you shouldn't use much public variables or
functions, only the ones that are really needed. So, with properties, we're
returning from OOP to structured programming.

"Carlos" <carlos8294@msn.com> ha scritto nel messaggio news:absptb$21vn$1@digitaldaemon.com...
>
> I can kill two birds with one shoot.
> Probably I'm too down in OOP theory, but here's the thing: there're some
> principles about OOP which are: encapsulate, hide, inheritance,
polimorfism,
> etc. When I say "hide" I mean "hide data to the user", not only funcionality. To do this, you shouldn't use much public variables or functions, only the ones that are really needed. So, with properties,
we're
> returning from OOP to structured programming.

No.
Properties are syntactic sugar, they are actually methods of the class,
they are not variables.
Look at them like a special pattern, when you have two methods
(the getter and the setter) that treat the same "property" of a class,
one to set it, the other to get it. What they actually do to get or set
this property isn't known to the public (they can connect to an
ftp site and up/download megabytes to do it, for example).

The advantage is from the user perspective: the syntax for variables
is a lot simpler than that of functions, so its use is incouraged.
I've noted that when properties are available programmers tend to
avoid using public variables and use properties instead.
OOP takes advantage from properties.

The power of laziness...

Ciao