Writing my previous post, I ended up with a problem:

class Foo
{
   int bar;
public:
   int bar() { return bar; };
};

In the basic definition of getters and setters, the line
   return bar;
should call the getter for bar, causing an infinite loop!

We need some sort of specification in the language to avoid this.  You could define that a setter or getter can't recursively call itself, but we're still left with a pathological case:

class Confusion
{
   int a,b;
public:
   int a() { return b; };
   int b() { return a; };
};

I'm leaning toward the idea that in a class member function, it will *always* use the underlying variable and not the getter and setter...but even that's not totally clean.

class Money // another pathological case
{
   float money;
public:
   void money(float dollars) { money = 100*dollars; };
   float money() { return money/100; };

public:
   void Add(float dollars) { money = money+dollars; }; // probably NOT
what the programmer wanted
};

I haven't seen anything about friend classes (is a class a friend of itself, like in Java?) - what happens when a friend class uses a property?

"Russ Lewis" <russ@deming-os.org> wrote in message news:3B82D980.B5E2E3E3@deming-os.org...
> I'm leaning toward the idea that in a class member function, it will *always* use the underlying variable and not the getter and setter...but

Seems the most logical to me.

"Russ Lewis" <russ@deming-os.org> wrote in message news:3B82D980.B5E2E3E3@deming-os.org...
> Writing my previous post, I ended up with a problem:
>
> class Foo
> {
>    int bar;
> public:
>    int bar() { return bar; };
> };
>
> In the basic definition of getters and setters, the line
>    return bar;
> should call the getter for bar, causing an infinite loop!
>
> We need some sort of specification in the language to avoid this.  You could define that a setter or getter can't recursively call itself, but we're still left with a pathological case:

.. My experience from using properties in Delphi & liking the way that Delphi does them: This isn't really a problem in Delphi, and no special rules are needed, just a sensible syntax for property declarations, where the gettor, settor and instance var need to have different names in order to compile, just like everything else in the class. For e.g:

class Foo
{
    int m_bar;
 public:
    int bar() { return m_bar; };
 };

Or something similar. You can't normally have a class with an instance var with the same name as a method, why should properties change that? See my previous comments for more detail.

Yes, in Delphi it is possible to miscode so that the property gettor calls itself, the equivalent of forgetting the 'm_' prefix in the above class. Yes, the program hangs the first time you run it. It's  easy to spot & easy to fix, so I don't see it as a real problem. I don't think that it is worth cluttering the language with a special feature for this.

> Or something similar. You can't normally have a class with an instance var with the same name as a method, why should properties change that? See my previous comments for more detail.

Well thats not a must be. For Pascel it's true since you don't have to use brackets for (void) functions the compiler couldn't tell which one you mean. For C it's also true, since the function name without brackets returns a pointer to the function, but suprisingly in java (and taken over to dtone :o) you can have a field and a function name with the same name. The compile can eitherway tell from you syntax which one you mean.

class cork {
   int a;
   void a() {return 5};
}

cork.a = cork.a();

I guess it's pretty clear which 'a' is meant when.


- Axel

Objective-C is the same. it will allow instance vars and methods to have the same name. (from Axel's example...)

@interface cork {
    int a;
}

- (void)a;

@end


--
e.sammer <eric@lifeless.net>


Axel Kittenberger wrote:

>>Or something similar. You can't normally have a class with an instance var
>>with the same name as a method, why should properties change that? See my
>>previous comments for more detail.
>>
> 
> Well thats not a must be. For Pascel it's true since you don't have to use brackets for (void) functions the compiler couldn't tell which one you mean. For C it's also true, since the function name without brackets returns a pointer to the function, but suprisingly in java (and taken over to dtone :o) you can have a field and a function name with the same name. The compile can eitherway tell from you syntax which one you mean. 
> 
> class cork {
>    int a;
>    void a() {return 5};
> }
> 
> cork.a = cork.a();
> 
> I guess it's pretty clear which 'a' is meant when.
> 
> 
> - Axel
> 

> to dtone :o) you can have a field and a function name with the same name. The compile can eitherway tell from you syntax which one you mean.

Hm, is this name-overloading either necessary or desirable?

Anthony Steele wrote:

> class Foo
> {
>     int m_bar;
>  public:
>     int bar() { return m_bar; };
>  };

<slap self>

This, of course, is the (trivial) solution.  However, to use it, we must change the spec a bit.  The spec is that you can expose gettors and settors for a specific variable of the same name.  Instead, the spec will have to say that if you declare a function that takes no arguments, then it can be called like a variable.  The compiler will have to differentiate between l-values and r-values to call the right function (or to determine that no applicable function exists).

> Hm, is this name-overloading either necessary or desirable?

Yes, at least if you don't have properties, in C++ you result having often the private field preceded with _ and a public access routine.

class Node {
    class Noe * _parent;

    public Node * parent() {return _parent;}

}

Now the fatal typo that can happen quickly when coding Node itself, is you write just parent meaning _parent, and handle in reality with function-pointer to parent()

- Axel

> > Hm, is this name-overloading either necessary or desirable?
>
"Axel Kittenberger" <axel@dtone.org> wrote in message news:<9n5u9u$1v5g$2@digitaldaemon.com>...

> Yes, at least if you don't have properties, in C++ you result having often the private field preceded with _ and a public access routine.
>
> class Node {
>     class Noe * _parent;
>
>     public Node * parent() {return _parent;}
>

But the key feature of your example is that you *don't* have a var and a function with the same name on the class. I repeat - I cannot think of any situation where it would be desirable or even necessary to allow a var and a function with the same name on the same class. Perhaps this is just brain-damage from too much Object-Pascal, but if I saw a class like

class Foo {
     int bar;

     public int bar() ...

}

My first impulse would not be to praise the coder's use of adavanced C-language-family features, but to slap them until they thought up better names. I'm sorry, I just don't see this feature as *in any way* useful, and IMHO it could easily be jetissoned to make way for better things, ie using public fn's, data and properties interchangeably.

Anthony

"Anthony Steele" <asteele@nospam.iafrica.com> wrote in message news:9ng2s3$1f7d$1@digitaldaemon.com...

> IMHO it could easily be jetissoned to make way for better things, ie using public fn's, data and properties interchangeably.
>

Further to this, language designers should learn from other people's mistakes: take a look at JWZ's essay "Why java sucks" at http://www.jwz.org/doc/java.html , in which explores what he sees as some of the flaws in Java. One point reads:

The distinction between slots and methods is stupid. Doing foo.x should be defined to be equivalent to foo.x(), with lexical magic for ``foo.x = ...'' assignment. Compilers should be trivially able to inline zero-argument accessor methods to be inline object+offset loads. That way programmers wouldn't break every single one of their callers when they happen to change the internal implementation of something from something which happened to be a ``slot'' to something with slightly more complicated behavior.