"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

> 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. >:->

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. >:->

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

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