View mode: basic / threaded / horizontal-split · Log in · Help
April 01, 2008
Re: Proposal request: explicit propreties
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.
April 01, 2008
Re: Proposal request: explicit propreties
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
April 01, 2008
Re: Proposal request: explicit propreties
"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
April 01, 2008
Re: Proposal request: explicit propreties
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
April 01, 2008
Re: Proposal request: explicit propreties
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 }
April 01, 2008
Re: Proposal request: explicit propreties
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
April 01, 2008
Re: Proposal request: explicit propreties
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
April 01, 2008
Re: Proposal request: explicit propreties
"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
April 01, 2008
Re: Proposal request: explicit propreties
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.
April 01, 2008
Re: Proposal request: explicit propreties
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
1 2 3
Top | Discussion index | About this forum | D home