Ary Borenszweig <ary esperanto.org.ar> writes:

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?

"Koroskin Denis" <2korden+dmd gmail.com> writes:

Agree. I have seen that both syntaxes are used (at some third party  =

library) and I believe it is an inconsistency.

On Tue, 01 Apr 2008 17:21:19 +0400, Ary Borenszweig <ary esperanto.org.a=
r>  =

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 =3D 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", et=

c.  =

 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?

Aarti_pl <aarti interia.pl> writes:

Ary Borenszweig pisze:

...

 I suggest marking properties as such like this:
 
 getter Type property() {
   // ...
 }
 
 setter void property() {
   // ...
 }
 

...

 What do you think?

Good rationale.

I just think that one keyword instead of setter/getter would be just 
enough. E.g 'property'.

BR
Marcin Kuszczak

Jacob Carlborg <doobnet gmail.com> writes:

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?

I like the way it is now because you don't have to write the () after a 
function call (taking no arguments) if you like but I understand why 
explicit properties would be a good thing. If explicit properties were 
introduced in the language I would like this syntax:

get T name (){}
set T name (){}

and also something I like to call property shortcut:

1) get string name;
2) set string name;
3) get set string name;
4) private set string name;
5) private set string name; public get string name;
6) static get string name;
7) get set
    {
	string name;
	int age;
	private string foo;
    }

that would work something like read and write attributes in Ruby.
1) creates a private variable and a public get method
2) creates a private variable and a public set method
3) creates a private variable and a public get and set method
4) creates a private variable and a private set method
5) creates a private variable, a private set method and a public get method
6) creates a private static variable and a public static get method
7) creates three private variables, two public set methods (name and 
age), two public get methods (name and age), a private set method (foo) 
and a private get method (foo)

The thing is that the variables always should be private, the methods 
would be public as default and if you put a protection attribute 
(public, private, protected ...) in front of a property shortcut it 
should affect only the created method.

"Koroskin Denis" <2korden+dmd gmail.com> writes:

In my opinion, it is over-complicated.

On Tue, 01 Apr 2008 18:05:41 +0400, Jacob Carlborg <doobnet gmail.com>  
wrote:

 Ary Borenszweig wrote:
 I like the way it is now because you don't have to write the () after a  
 function call (taking no arguments) if you like but I understand why  
 explicit properties would be a good thing. If explicit properties were  
 introduced in the language I would like this syntax:

 get T name (){}
 set T name (){}

 and also something I like to call property shortcut:

 1) get string name;
 2) set string name;
 3) get set string name;
 4) private set string name;
 5) private set string name; public get string name;
 6) static get string name;
 7) get set
     {
 	string name;
 	int age;
 	private string foo;
     }

 that would work something like read and write attributes in Ruby.
 1) creates a private variable and a public get method
 2) creates a private variable and a public set method
 3) creates a private variable and a public get and set method
 4) creates a private variable and a private set method
 5) creates a private variable, a private set method and a public get  
 method
 6) creates a private static variable and a public static get method
 7) creates three private variables, two public set methods (name and  
 age), two public get methods (name and age), a private set method (foo)  
 and a private get method (foo)

 The thing is that the variables always should be private, the methods  
 would be public as default and if you put a protection attribute  
 (public, private, protected ...) in front of a property shortcut it  
 should affect only the created method.

Leandro Lucarella <llucax gmail.com> writes:

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.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Es mas posible, que un elefante maneje un cero km a que un camello
habite un departamento de un ambiente.
	-- Peperino Pómoro

Ary Borenszweig <ary esperanto.org.ar> writes:

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.

Kenny B <funisher gmail.com> writes:

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.

Lionello Lunesu <lio lunesu.remove.com> writes:

Ary Borenszweig wrote:
 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;

Code that doesn't make sense is always ugly.

Furthermore, I think that particular case can be fixed without removing 
the current syntax by limiting it's scope to functions with a single 
argument.

 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.

The whole point of property is that you can simply leave it as a 
function and the compiler will inline it if it turns out to be a trivial 
get/set. You're reasoning here is the wrong way around.

 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.

This I don't get. Whether you want dummy "()" or not sounds like a 
style, much like space vs. tab, or tab size. IDE's can make it a user 
setting.

 Of course, this is not backwards compatible, so it should be a D2 feature.
 
 What do you think?

I like the current "implicit getter/setter" very much and think it's one 
of the nicest features of D!

L.

Ary Borenszweig <ary esperanto.org.ar> writes:

Lionello Lunesu wrote:
 Ary Borenszweig wrote:
 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;

 
 Code that doesn't make sense is always ugly.
 
 Furthermore, I think that particular case can be fixed without removing 
 the current syntax by limiting it's scope to functions with a single 
 argument.
 
 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.

 
 The whole point of property is that you can simply leave it as a 
 function and the compiler will inline it if it turns out to be a trivial 
 get/set. You're reasoning here is the wrong way around.

To me, the idea of a property is: you use it as it were a field of a 
struct/class, but it's actually implemented by a function. You want to 
hide the implementation details from the user. You don't want them to 
know "Foo.property" is actually a function.

 
 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.

 
 This I don't get. Whether you want dummy "()" or not sounds like a 
 style, much like space vs. tab, or tab size. IDE's can make it a user 
 setting.

Take a look a this, from DFL:

---
class Form {

   /// Sets the title of this form
   void title(string text) {
     // ...
   }

}

class Application {

  /// Runs an application whose main form is the given
  static void run(Form form) {
    //
  }

}
---

Now you wan to code:

---
Form form = new Form();
form.title // <-- you wan't the IDE to suggest you a property, so
            // you will end up having "form.title = text"

Application.run // <-- you wan't the IDE to suggest you a function,
                 // like "Application.run(form)"
                 // "Application.run = form" looks ugly, and no one
                 // would recommend you to write that
---

How do you configure this? On a per-property basis?

 
 Of course, this is not backwards compatible, so it should be a D2 
 feature.

 What do you think?

 
 I like the current "implicit getter/setter" very much and think it's one 
 of the nicest features of D!
 
 L.

"Lionello Lunesu" <lionello lunesu.remove.com> writes:

"Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
news:fsti15$a9s$1 digitalmars.com...
 Lionello Lunesu wrote:
 The whole point of property is that you can simply leave it as a function 
 and the compiler will inline it if it turns out to be a trivial get/set. 
 You're reasoning here is the wrong way around.

 To me, the idea of a property is: you use it as it were a field of a 
 struct/class, but it's actually implemented by a function. You want to 
 hide the implementation details from the user. You don't want them to know 
 "Foo.property" is actually a function.

That's what I meant: why would you ever want to change a property 'function' 
into a data member? You'll end up with less flexibility, and gain nothing.

 Take a look a this, from DFL:

 ---
 class Form {

   /// Sets the title of this form
   void title(string text) {
     // ...
   }

 }

 class Application {

  /// Runs an application whose main form is the given
  static void run(Form form) {
    //
  }

 }
 ---

 Now you wan to code:

 ---
 Form form = new Form();
 form.title // <-- you wan't the IDE to suggest you a property, so
            // you will end up having "form.title = text"

 Application.run // <-- you wan't the IDE to suggest you a function,
                 // like "Application.run(form)"
                 // "Application.run = form" looks ugly, and no one
                 // would recommend you to write that
 ---

 How do you configure this? On a per-property basis?

It appears that in both cases the user has knowledge whether the member 
should be assigned or invoked. The IDE will simply suggest "title" or "run" 
and pressing "=" or "(" key will finish the job, yielding either "title=" or 
"run(".

Unless you mean the IDE should have suggested the "=" and "(" as well, but I 
have never seen an auto-complete that suggests more than just the name. And 
it sounds like it shouldn't suggest more than that; what if I want a ptr to 
member function?

My suggestion for a user setting applies to getters. There, when the IDE 
shows a suggested function/getter, pressing ";" will finish the line and 
optionally add a pair of ().

L. 

Christopher Wright <dhasenan gmail.com> writes:

Lionello Lunesu wrote:
 It appears that in both cases the user has knowledge whether the member 
 should be assigned or invoked. The IDE will simply suggest "title" or 
 "run" and pressing "=" or "(" key will finish the job, yielding either 
 "title=" or "run(".
 
 Unless you mean the IDE should have suggested the "=" and "(" as well, 
 but I have never seen an auto-complete that suggests more than just the 
 name. And it sounds like it shouldn't suggest more than that; what if I 
 want a ptr to member function?

Actually, Descent does this, and I find it amusing sometimes.

Ary Borenszweig <ary esperanto.org.ar> writes:

Lionello Lunesu escribió:
 
 "Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
 news:fsti15$a9s$1 digitalmars.com...
 Lionello Lunesu wrote:

 It appears that in both cases the user has knowledge whether the member 
 should be assigned or invoked. The IDE will simply suggest "title" or 
 "run" and pressing "=" or "(" key will finish the job, yielding either 
 "title=" or "run(".
 
 Unless you mean the IDE should have suggested the "=" and "(" as well, 
 but I have never seen an auto-complete that suggests more than just the 
 name. And it sounds like it shouldn't suggest more than that; what if I 
 want a ptr to member function?
 
 My suggestion for a user setting applies to getters. There, when the IDE 
 shows a suggested function/getter, pressing ";" will finish the line and 
 optionally add a pair of ().
 
 L.

Those are great suggestions!

Eclipse for Java (JDT) suggests you more than the function of the name: 
it writes, for example:

String s = ...;
s.substring // <-- autocomplete!

and you get

s.substring(start, end)

with "start" highlighted, so if you start typying, you overwrite 
"start". If you press tab, the focus goes to the next parameter ("end" 
in this case), etc. I find if very comfortable not to have to type those 
"(", ",", ")". But... in Java you can't have pointers to functions. But 
I think in those cases for D, the IDE can more or less figure out that 
the user wants just the name: if it is assigning it to a function 
pointer or delegate (but this is not true all the time).

Anyway, I liked the "=" and "(" method of distinguishing property vs. 
method. I'll try to implement it. :-)

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

Lionello Lunesu wrote:
 name. And it sounds like it shouldn't suggest more than that; what if I 
 want a ptr to member function?

Then you typed a '&' before the expression you're auto-completing?

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Tue, 01 Apr 2008 15:21:19 +0200, Ary Borenszweig <ary esperanto.org.a=
r>  =

wrote:

 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?

I like it the way it is. It's simple and, for the most part, logical.  =

Though as
you say, it might be a problem for IDEs. However, I think if D should ha=
ve
properties, that one should be able to customize them more. I've been  =

working on
a property struct template, which allows you to customize its access (i.=
e
read-only, write-only, allow only certain operators...), as well as mixi=
n
fuctions of your choice. And the syntax is pretty simple (though not  =

perfect. I
wish there was some way to have it set up automagically, not in the
constructor):

   class foo
   {
     private:
       int _bar;
       float _baz;
     public:
         // read-write property
       property!(int, property.readwrite) bar;
         // custom property that allows only addition and subtraction
       property!(float, property.custom, "+,-", "+,-", "+=3D, -=3D") baz=
;

     this()
     {
       bar =3D &_bar;
       baz =3D &_baz;
     }
   }

   foo f =3D new foo;
   f.bar +=3D 3;

I believe something like this would be more useful, as long as there wer=
e  =

some
standard way to do it. Also, the syntax to mixin templates could do with=
  =

some
sugar. What I'd really want'd be something like this:

   class foo
   {
     private:
       int _bar;
       float _baz
       string _faz;
     public:
       property!(_bar) bar;
       property!(_baz, read) baz;
       property!(_faz){
         // methods to be mixed in
       } baz;
   }


--Simen

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"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?



Type property
{
   get
   {
         ....
   }
   set
   {
         ....
   }
}

get and set don't have to be keywords in this context...

All in all, I'm not really upset with the way properties currently work, but 
I do prefer something explicit like this.

-Steve 

Bill Baxter <dnewsgroup billbaxter.com> writes:

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

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"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 

Bill Baxter <dnewsgroup billbaxter.com> writes:

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

naryl <cy ngs.ru> writes:

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 =3D ([1, 3, 2, 5, 4].dup);
   5     a.popHeap();	//Doesn't compiles without terminal ()
   6 }

Bill Baxter <dnewsgroup billbaxter.com> writes:

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

Derek Parnell <derek psych.ward> writes:

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

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"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 

Yigal Chripun <yigal100 gmail.com> writes:

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

Robert Fraser <fraserofthenight gmail.com> writes:

Ary Borenszweig wrote:
 [snip]
 
 What do you think?

Whatever property syntax is chosen, I believe it should enable 
properties to work as first-class values. So if you have a class 
instance frail with property loops, you should be able to do 
frail.loops++, &frail.loops, and all the other wonderful things 
impossible with properties currently.

This has already been discussed a number of times before, and Walter has 
agreed a change might be necessary (see this post: 
http://tinyurl.com/2s4x6q ), but it's not a priority right now.