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