www.digitalmars.com         C & C++   DMDScript  

D - properties tutorial?

reply "Sandor Hojtsy" <hojtsy index.hu> writes:
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
May 14 2002
next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
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))) ]
May 14 2002
parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
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.
May 14 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"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.
May 14 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"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.
May 14 2002
prev sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"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...
May 14 2002
parent reply "Carlos" <carlos8294 msn.com> writes:
 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
May 14 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"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...
May 14 2002
parent reply "Carlos" <carlos8294 msn.com> writes:
"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.
May 14 2002
next sibling parent "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"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
May 15 2002
prev sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
"Carlos" <carlos8294 msn.com> wrote in message
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.


I think that's unwarranted.

A property is a fundamentally different concept than variable or
function/method.

A property is a small set of functions that, together, behave as one member
variable would.  The functions are selected among depending on the usage of
the property:  stores go to one function, reads go to another.  Either or
both can be public, private, or missing altogether.

The idea behind encapsulation is to hide the details of a process from other
code that doesn't need to concern itself with such details, to reduce
dependencies on things that might change in the future.  Properties are neat
because they can hide functionality without requiring any client code
changes.  A variable or a property of the same type are semantically
interchangeable to clients.  The behavior is the same as a variable.  But it
allows the host class an opportunity to place some buffer or control on such
accesses.

Sometimes the best way to implement a class is to leave a piece of data or
two completely public to the class.  It certainly is true that it is far
easier to use member variables than get/set functions.  Properties allow
"transparent" get/set functions which are just as easy to use as variables.
Most convenient.

Like any language feature, it can be prone to misuse.  If it's a bad design
decision to expose a member variable as public, it's probably also a bad
design desision to make a similar property public.  But I'd much rather have
properties than get/set functions.

Sean
May 15 2002
parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
 The idea behind encapsulation is to hide the details of a process from


other

 code that doesn't need to concern itself with such details, to reduce
 dependencies on things that might change in the future.  Properties are


neat

 because they can hide functionality without requiring any client code
 changes.  A variable or a property of the same type are semantically
 interchangeable to clients.  The behavior is the same as a variable.


No.
You can't get a pointer or form a reference to a property, or can you?
So client code breaks anyway.
The only thing you can do is start with properties from the begining,
therefore practically disabling the two mentioned features.
Then you can a have a lintD which suggests you to change all public
valiables to properties, or a language "extension" which makes it possible
to disable these two features in advance, thinking to the possible
future change to property. >:->
May 15 2002
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
You know what, Walter?  Since allowing folks to make inner pointers to class
member variables causes so many other problems, maybe you should just
disallow them.

You're right though you can't make a reference to a property... hadn't
thought of that.

Sean

"Sandor Hojtsy" <hojtsy index.hu> wrote in message
news:abt95f$2hbp$1 digitaldaemon.com...

 The idea behind encapsulation is to hide the details of a process from


 other

 code that doesn't need to concern itself with such details, to reduce
 dependencies on things that might change in the future.  Properties are


 neat

 because they can hide functionality without requiring any client code
 changes.  A variable or a property of the same type are semantically
 interchangeable to clients.  The behavior is the same as a variable.


 No.
 You can't get a pointer or form a reference to a property, or can you?
 So client code breaks anyway.
 The only thing you can do is start with properties from the begining,
 therefore practically disabling the two mentioned features.
 Then you can a have a lintD which suggests you to change all public
 valiables to properties, or a language "extension" which makes it possible
 to disable these two features in advance, thinking to the possible
 future change to property. >:->
May 15 2002
parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
 You know what, Walter?  Since allowing folks to make inner pointers to


class

 member variables causes so many other problems, maybe you should just
 disallow them.


You mean disallow this?

class my_class {
  int a;
}

void fn()
{
  my_class  my_object = new my_class;
  int *p = &my_object.a;
}
May 16 2002
parent "Sean L. Palmer" <spalmer iname.com> writes:
Yeah, sort of... like the object itself knows the addresses of its members,
but to all other objects, the addresses are private.  The variables can be
used but the references can't be stored except for on the stack.

Probably no clean way to do this.

Sean

"Sandor Hojtsy" <hojtsy index.hu> wrote in message
news:abvm7t$1iai$1 digitaldaemon.com...

 You know what, Walter?  Since allowing folks to make inner pointers to


 class

 member variables causes so many other problems, maybe you should just
 disallow them.


 You mean disallow this?

 class my_class {
   int a;
 }

 void fn()
 {
   my_class  my_object = new my_class;
   int *p = &my_object.a;
 }
May 16 2002