"Derek Parnell" <derek@psych.ward> wrote ...
> On Fri, 06 Jan 2006 05:52:44 +1100, Kris <fu@bar.com> wrote:
>
>
> [snip]
> Yes, I understood all of that but the difference is in how you refer to
> the 'property'. With a true property it would
>
>     X = A.goofy;
>
> and in your version it would be
>
>     X = A.getGoofy();


Isn't that's just a naming concern? The method approach could just as easily be:

float goofy()
{
   return XYZ;
}

Thus producing

X = A.goofy();

which the compiler will currently map to

X = A.goofy;



> The difference is not just how much you type in. For example the original version of the class might have defined 'goofy' as just ...
>
>      float goofy;
>
> So code referring to it would have been ...
>
>     X = A.goofy;
>
> And then later when it was turned into a property, that type of reference would not also have to be changed but if the function-type property was implemented (ala your example) all references to 'goofy' would also have to be changed.

I thought the compiler currently supports method references in an identical manner e.g. X = A.goofy;

Does it not?

Kris wrote:
> I thought the compiler currently supports method references in an identical manner e.g. X = A.goofy;
> 
> Does it not?

It does, although the last time I tried playing with this syntax, it would break in random places, requiring the addition of the parenthesis to resolve correctly.  That might have been mostly resolved, though; I don't know.

-- Chris Sauls

Doh! Forgot to add something:

"Derek Parnell" <derek@psych.ward> wrote ..
> On Fri, 06 Jan 2006 05:52:44 +1100, Kris <fu@bar.com> wrote:
> [snip]
> The difference is not just how much you type in. For example the original
> version of the class might have defined 'goofy' as just ...
>
>      float goofy;
>
> So code referring to it would have been ...
>
>     X = A.goofy;
>
> And then later when it was turned into a property, that type of reference would not also have to be changed but if the function-type property was implemented (ala your example) all references to 'goofy' would also have to be changed.

This is a refactoring issue, which is surely a much larger problem than the specific handling of 'properties'? For example, what happens when I want to change the name of a method? Or the order of method-arguments? Or the types or number of arguments? Or the name of a class? etc.etc.

As a recent post noted, this is the domain of 3rd party tools, such as Eclipse or IntelliJ, which handle just this kind of thing with aplomb. It is certainly a delight to heavily refactor a large body of code in just a few minutes rather than possibly days of tedious grunt-work. And to do it all in a manner that does not introduce errors <g>

A refactoring module for one of the developing D IDE would be a very useful thing to have.

- Kris

"Chris Sauls" <ibisbasenji@gmail.com> wrote ...
> Kris wrote:
>> I thought the compiler currently supports method references in an identical manner e.g. X = A.goofy;
>>
>> Does it not?
>
> It does, although the last time I tried playing with this syntax, it would break in random places, requiring the addition of the parenthesis to resolve correctly.  That might have been mostly resolved, though; I don't know.

OK, Gotcha. I think that's still the case? It seems to be that it always works from within an expression e.g. if (x.goofy) ...  but sometimes fails when used as the rValue of an assignment?

Should that be reported as a bug?

How about simply adding a 'property' attribute? The compiler could at least enforce more rules with it, like making sure the get/set types match, allow them to be used more like fields, not allow them to be used like functions (which the magic, built-in ones already enforce (inconsistent)), and not allow regular functions to be used as properties.
Example:


private int _foo = 1;

   property int foo() { return 3; }


Or use a property block to group them, since it's an attribute:


   property
   {
      int foo() { return 3; }
      void foo(int value) { _foo = value; }
   }


Yes, there's duplicated information, but it's much simpler on the compiler and will require minimal changes to existing code.
- Chris

"Chris Miller" <chris@dprogramming.com> wrote
> How about simply adding a 'property' attribute? The compiler could at least enforce more rules with it, like making sure the get/set types match, allow them to be used more like fields, not allow them to be used like functions (which the magic, built-in ones already enforce (inconsistent)), and not allow regular functions to be used as properties. Example:
>
>
> private int _foo = 1;
>
>    property int foo() { return 3; }
>
>
> Or use a property block to group them, since it's an attribute:
>
>
>    property
>    {
>       int foo() { return 3; }
>       void foo(int value) { _foo = value; }
>    }
>
>
> Yes, there's duplicated information, but it's much simpler on the compiler and will require minimal changes to existing code.


I'm still trying to get a handle on this, Chris, so please forgive the naiive questions:

a) Is this based on a desire to use 'property' methods as lValues?

b) what exactly are the characteristics that distinguish a 'property' method from a 'normal' one?

- Kris

On Thu, 05 Jan 2006 17:24:16 -0500, Kris <fu@bar.com> wrote:

> "Chris Miller" <chris@dprogramming.com> wrote
>> How about simply adding a 'property' attribute? The compiler could at
>> least enforce more rules with it, like making sure the get/set types
>> match, allow them to be used more like fields, not allow them to be used
>> like functions (which the magic, built-in ones already enforce
>> (inconsistent)), and not allow regular functions to be used as properties.
>> Example:
>>
>>
>> private int _foo = 1;
>>
>>    property int foo() { return 3; }
>>
>>
>> Or use a property block to group them, since it's an attribute:
>>
>>
>>    property
>>    {
>>       int foo() { return 3; }
>>       void foo(int value) { _foo = value; }
>>    }
>>
>>
>> Yes, there's duplicated information, but it's much simpler on the compiler
>> and will require minimal changes to existing code.
>
>
> I'm still trying to get a handle on this, Chris, so please forgive the
> naiive questions:
>
> a) Is this based on a desire to use 'property' methods as lValues?

No, so that you can't use properties as functions and you can't use functions as properties, so they're used as intended; and the other reasons I explained above; also so that documentation generation like Ddoc can output function or property as appropriate.

>
> b) what exactly are the characteristics that distinguish a 'property' method
> from a 'normal' one?

property attribute; personal preference to have property or method.. not sure what you want me to say here beyond what I already said.

"Chris Miller" <chris@dprogramming.com> wrote ...
[snip]
>> I'm still trying to get a handle on this, Chris, so please forgive the naiive questions:
>>
>> a) Is this based on a desire to use 'property' methods as lValues?
>
> No, so that you can't use properties as functions and you can't use functions as properties, so they're used as intended;


I'll admit that I don't see a solid semantic distinction (at the code-usage level) between 'property' methods and 'normal' methods (or did you mean some other kind of function?). They are both an exposure of capability via some level of abstraction. They can both set or expose internal state. They can both be arbitrarily complex or completely trivial. They are both intended to encapsulate behaviour specific to their containing entity. Why is one somehow special? I don't get it :-(

> and the other reasons I explained above;

While it does seem reasonable for set/get to be consistent in type usage, it's not necessarily a hard rule. If it were, some people might use 'functions' instead of 'properties' to get around it, leading to other problems? And, could this kind of thing (auto-generation of appropriate methods, with consistent types) perhaps be handled by an IDE, similar to the refactoring angle? Do Eclipse and IntelliJ (etc) do it this way?

> also so that documentation generation like Ddoc  can output function or property as appropriate.

That makes sense only if you view them as sematically distinct from a code usage-aspect?

OTOH, I do see a usage distinction regarding IDE handling of properties, such as property sheets and so on? But that seems quite different from a code-usage perpective ~ instead, IDE property sheets expose an alternative to explicit, configuration of components? If so, could the notion of a 'property' be just some kind of convenient tagging that an IDE looks for? For example:

class X
{
    property double velocity;
    property char[] description;

    ...
}

Perhaps the notion could be used by an IDE to expand into other composite aggregates? e.g.

class Y
{
    property int something;
    property X x;
    ...
}

There would presumeably be no need to do the same via inheritance?  Perhaps, with introspection, such a tag might be useful for other things? These examples use 'property' purely for attribute-decoration only ~ they don't change the behaviour of the compiler per se, except perhaps to imply "private"?

- Kris

I myself see setters & getters being different from ordinary functions:

1) Set always is passed a single parameter and returns void.
2) Get always returns a single type.
3) Set will always change the state of an object (unless rvalue is current
value).  Functions don't necessarily change the state of the value.
4) Get and Set provide a standardization to access the properties of an object.
Otherwise we could have code like car.setwheelcount(4), assert
(car.passengerscount(4)!=0) and if(car.wiperblades()=3) { writefln("mgb!\n") }


Tom J

From http://c2.com/cgi/wiki?AccessorsAreEvil

..Setters and Getters are different breeds of dog.

A setter involves this-here-object modifying the state of that-there-object. This almost always creates maintenence problems and is smelly in the extreme.

If fu needs data from bar because (and only because) bar is the authoritative source or an agent of the authoritative source (users, databases and other outside things need agents), then bar needs to provide a getter interface for fu to use. There are a half-dozen design patterns to choose from that let bar tell any and all interested fus that new or changed data is available and to "come and get it". Since fu is in control, and the coupling is kept to the minimum required for bar to provide its service, it doesn't smell at all. This is the essence of MVC.


In article <dpkeff$462$1@digitaldaemon.com>, Kris says...
>
>"Chris Miller" <chris@dprogramming.com> wrote ...
>[snip]
>>> I'm still trying to get a handle on this, Chris, so please forgive the naiive questions:
>>>
>>> a) Is this based on a desire to use 'property' methods as lValues?
>>
>> No, so that you can't use properties as functions and you can't use functions as properties, so they're used as intended;
>
>
>I'll admit that I don't see a solid semantic distinction (at the code-usage level) between 'property' methods and 'normal' methods (or did you mean some other kind of function?). They are both an exposure of capability via some level of abstraction. They can both set or expose internal state. They can both be arbitrarily complex or completely trivial. They are both intended to encapsulate behaviour specific to their containing entity. Why is one somehow special? I don't get it :-(
>
>> and the other reasons I explained above;
>
>While it does seem reasonable for set/get to be consistent in type usage, it's not necessarily a hard rule. If it were, some people might use 'functions' instead of 'properties' to get around it, leading to other problems? And, could this kind of thing (auto-generation of appropriate methods, with consistent types) perhaps be handled by an IDE, similar to the refactoring angle? Do Eclipse and IntelliJ (etc) do it this way?
>
>> also so that documentation generation like Ddoc  can output function or property as appropriate.
>
>That makes sense only if you view them as sematically distinct from a code usage-aspect?
>
>OTOH, I do see a usage distinction regarding IDE handling of properties, such as property sheets and so on? But that seems quite different from a code-usage perpective ~ instead, IDE property sheets expose an alternative to explicit, configuration of components? If so, could the notion of a 'property' be just some kind of convenient tagging that an IDE looks for? For example:
>
>class X
>{
>    property double velocity;
>    property char[] description;
>
>    ...
>}
>
>Perhaps the notion could be used by an IDE to expand into other composite aggregates? e.g.
>
>class Y
>{
>    property int something;
>    property X x;
>    ...
>}
>
>There would presumeably be no need to do the same via inheritance?  Perhaps, with introspection, such a tag might be useful for other things? These examples use 'property' purely for attribute-decoration only ~ they don't change the behaviour of the compiler per se, except perhaps to imply "private"?
>
>- Kris
>
>

"Kris" <fu@bar.com> wrote in message news:dpkeff$462>
> I'll admit that I don't see a solid semantic distinction (at the
code-usage
> level) between 'property' methods and 'normal' methods (or did you mean
some
> other kind of function?). They are both an exposure of capability via some level of abstraction. They can both set or expose internal state. They can both be arbitrarily complex or completely trivial. They are both intended
to
> encapsulate behaviour specific to their containing entity. Why is one somehow special? I don't get it :-(
>

Let me cite Dylan Reference Manual:
"
Order of execution aside, the following pairs of function calls are
equivalent:

america.capital
capital(america)

window.position
position(window)
"
and:
"
name(arg1,...argn ) := new-value

behaves exactly the same as

begin
  let temp = new-value;
  name-setter(temp, arg1,...argn );
  temp
end
"
(note: ':=' is Dylan assigment operator as it is '=' in D)

No semantics here! Programmers add semantics.
What is importan here to have SIMPLE and CONSISTENT GENERAL rule!
No special cases. It's beter for programmer and compiler :)

At first look D here remembers me Dylan, but it was only half way.

Zeljko