www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Proposal request: explicit propreties

reply 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?
Apr 01 2008
next sibling parent "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?
Apr 01 2008
prev sibling next sibling parent 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
Apr 01 2008
prev sibling next sibling parent reply 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.
Apr 01 2008
next sibling parent "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.
Apr 01 2008
prev sibling parent reply 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
Apr 01 2008
parent reply 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.
Apr 01 2008
parent 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.
Apr 01 2008
prev sibling next sibling parent reply 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.
Apr 01 2008
parent reply 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.
Apr 01 2008
parent reply "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.
Apr 01 2008
next sibling parent 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.
Apr 01 2008
prev sibling next sibling parent 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. :-)
Apr 01 2008
prev sibling parent 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?
Apr 02 2008
prev sibling next sibling parent "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
Apr 01 2008
prev sibling next sibling parent "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
Apr 01 2008
prev sibling next sibling parent reply 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
Apr 01 2008
parent reply "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
Apr 01 2008
next sibling parent reply 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
Apr 01 2008
parent reply 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 }
Apr 01 2008
parent 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
Apr 01 2008
prev sibling parent reply 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
Apr 01 2008
parent "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
Apr 01 2008
prev sibling next sibling parent 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
Apr 01 2008
prev sibling parent 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.
Apr 01 2008