Leandro Lucarella wrote:
> Jacob Carlborg, el  1 de abril a las 16:05 me escribiste:
>> get T name (){}
>> set T name (){}
> 
> I don't think making 'get' and 'set' keywords is a good idea.
> 
> I like the 'property' keyword, it's just one keyword and it's used in
> Python for the same thing.
> 

Me too.

Ary Borenszweig wrote:
> Currently properties can have these forms:
> 
> Getter:
> -------
> Type property() {
>   // ...
> }
> 
> Setter:
> -------
> void property(Type type) {
>   // ...
> }
> 
> The problem is, the user can use them as functions or as properties. This is ok from the compiler point of view, but the code looks ugly if it doesn't make sense, like:
> 
> writefln = 5;

I'm vaguely for designating properties as such, like you suggest, but I have some reservations:

Nobody would write code like writefln=5, but I have seen code that used this:

   writefln;

Is that so wrong? Anyway, some people seem to think that's a nice way to write zero-arg function calls.

I've also run across cases where the compiler fails to realize it should call a property method unless you explicitly put the () after it.  I can't recall exactly where.  That's just a bug, but it is something to consider.

Finally, getters and setters are prime targets for signal/slot callbacks.  So I would hope that despite .foo(5) being invalid, that you could still take the address of the property setter method to pass it to a callback setter.  But I guess that kind of defeats the purpose.  Hmm.  Maybe this works?:
     setCallback( (int x) { myFoo.prop = x; } )
I guess that works in D2 with it's full closures, but not D1 because the myFoo will go out of scope.  But still it seems unsatisfying to heap allocate an extra closure there, when .prop is actually a function to begin with.

On the other hand, taking addresses of an overloaded method is a hit-or-miss situation right now anyway, so maybe it's a good idea to use the lambda anyway (in D2).

--bb

"Bill Baxter" wrote
> I've also run across cases where the compiler fails to realize it should call a property method unless you explicitly put the () after it.  I can't recall exactly where.  That's just a bug, but it is something to consider.

It's when the object being returned by a property overloads opCall.  The prime example I know is tango's Stdout.newline():

Stdout("hello").newline()("world").newline;

If you don't include the extra (), then the compiler thinks you're calling newline("world");

This is one case where the nature of D properties is exploited in a way that would be unnatural with explicit properties.  newline is clearly not a property, but using it in this way is pretty clear (and convenient).

-Steve

Steven Schveighoffer wrote:
> "Bill Baxter" wrote
>> I've also run across cases where the compiler fails to realize it should call a property method unless you explicitly put the () after it.  I can't recall exactly where.  That's just a bug, but it is something to consider.
> 
> It's when the object being returned by a property overloads opCall.  The prime example I know is tango's Stdout.newline():
> 
> Stdout("hello").newline()("world").newline;
> 
> If you don't include the extra (), then the compiler thinks you're calling newline("world");
> 
> This is one case where the nature of D properties is exploited in a way that would be unnatural with explicit properties.  newline is clearly not a property, but using it in this way is pretty clear (and convenient).

No, that's not the one I was thinking of.  I have seen cases where the terminal () was required.  Next time I run into it I'll try to make a repro.

--bb

On Tue, 01 Apr 2008 23:39:10 +0400, Bill Baxter <dnewsgroup@billbaxter.com> wrote:

> Steven Schveighoffer wrote:
>> "Bill Baxter" wrote
>>> I've also run across cases where the compiler fails to realize it should call a property method unless you explicitly put the () after it.  I can't recall exactly where.  That's just a bug, but it is something to consider.
>>  It's when the object being returned by a property overloads opCall.  The prime example I know is tango's Stdout.newline():
>>  Stdout("hello").newline()("world").newline;
>>  If you don't include the extra (), then the compiler thinks you're calling newline("world");
>>  This is one case where the nature of D properties is exploited in a way that would be unnatural with explicit properties.  newline is clearly not a property, but using it in this way is pretty clear (and convenient).
>
> No, that's not the one I was thinking of.  I have seen cases where the terminal () was required.  Next time I run into it I'll try to make a repro.
>
> --bb

The other case is when you call an array property like tango.core.Array.popHeap.

  1 import tango.core.Array;
  2
  3 void main() {
  4     int[] a = ([1, 3, 2, 5, 4].dup);
  5     a.popHeap();	//Doesn't compiles without terminal ()
  6 }

naryl wrote:
> On Tue, 01 Apr 2008 23:39:10 +0400, Bill Baxter <dnewsgroup@billbaxter.com> wrote:
> 
> The other case is when you call an array property like tango.core.Array.popHeap.
> 
>   1 import tango.core.Array;
>   2
>   3 void main() {
>   4     int[] a = ([1, 3, 2, 5, 4].dup);
>   5     a.popHeap();    //Doesn't compiles without terminal ()
>   6 }

Yeh, that might be the one I'm thinking of.

--bb

On Tue, 1 Apr 2008 14:53:33 -0400, Steven Schveighoffer wrote:

> Stdout("hello").newline()("world").newline;

> ... using it in this way is pretty clear (and convenient).

?!Clear?! I haven't a clue what that code is supposed to be doing!

Is it ...

   Send "hello" to stdout.
   Send newline to stdout.
   Send "world" to stdout.
   Send newline to stdout.

If so, then the example is clear as mud. I think I prefer ...

   Stdout("hello", newline, "world", newline);

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

"Derek Parnell" wrote
> On Tue, 1 Apr 2008 14:53:33 -0400, Steven Schveighoffer wrote:
>
>> Stdout("hello").newline()("world").newline;
>
>> ... using it in this way is pretty clear (and convenient).
>
> ?!Clear?! I haven't a clue what that code is supposed to be doing!
>
> Is it ...
>
>   Send "hello" to stdout.
>   Send newline to stdout.
>   Send "world" to stdout.
>   Send newline to stdout.
>
> If so, then the example is clear as mud. I think I prefer ...
>
>   Stdout("hello", newline, "world", newline);

Heh, I just meant how newline can be used as a property rather than a function, even though newline isn't a true property.

Stdout("hello").newline;
Stdout("world").newline;

is most likely how I would write it, probably to avoid having the extra ().

-Steve

Ary Borenszweig wrote:
> Leandro Lucarella wrote:
>> Jacob Carlborg, el  1 de abril a las 16:05 me escribiste:
>>> get T name (){}
>>> set T name (){}
>>
>> I don't think making 'get' and 'set' keywords is a good idea.
>>
>> I like the 'property' keyword, it's just one keyword and it's used in
>> Python for the same thing.
>>
> 
> Me too.

Me too, cause if I had get/set as a keyword, it would break a lot of existing functions with the name get / set.

Ary Borenszweig wrote:
> Currently properties can have these forms:
>
> Getter:
> -------
> Type property() {
>   // ...
> }
>
> Setter:
> -------
> void property(Type type) {
>   // ...
> }
>
> The problem is, the user can use them as functions or as properties. This is ok from the compiler point of view, but the code looks ugly if it doesn't make sense, like:
>
> writefln = 5;
>
> Further, if you want a function to be only used with property syntax, you can't. Why would you wan't that? Because if you have
>
> class Foo {
>
>   int property() {
>     //
>   }
>
> }
>
> and then you decide to change it to
>
> class Foo {
>
>   int property;
>
> }
>
> for some reason, code that used Foo.property() won't compile anymore.
>
> I suggest marking properties as such like this:
>
> getter Type property() {
>   // ...
> }
>
> setter void property() {
>   // ...
> }
>
> "getter" and "setter" are attributes, just like "public", "static", etc. The compiler only uses them to validate correct syntax usage. If they are applied to any other declaration that is not a function, an error is reported.
>
> Finally, there is another reason for wanting to mark functions as properties: when you do autocompletion in an IDE, and it suggests you a function, it can't know whether to autocomplete it as a function or as a property. A solution could be writing something in the ddoc of that function, but since there's no standard for this, each IDE will invent it's own.
>
> Of course, this is not backwards compatible, so it should be a D2 feature.
>
> What do you think?
what about the other way around - instead of making properties explicit,
generalize implicit properties to any number or parameters. for example,
say your GUI lib has a function to set the size of a window:
void windowSize(int a, int b);
now you'd be able to call it with:
windowSize = 800, 600;
or for the getter ( for that to work, D needs to implement tuple return
types):
Stdout(windowSize);

the user should choose what ever notation makes more sense for the specific case and IMO an IDE should probably default to the function calling syntax, as it makes sense for all cases while the property syntax does not.

--Yigal