www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - property

reply Pelle <pelle.mansson gmail.com> writes:
As heard around these parts, a lot of people want property-style 
function calls to require the function to be declared with  property, 
like this:

 property foo(); //getter
 property foo(int); //setter

foo; //getter
foo = 13; //setter

While this seems quite reasonable, in practice I and others feel this 
leads to confusion, especially the getter part. Mostly when the getter 
has no setter counterpart. D also lets us call no-argument functions 
without parentheses today, so for this to happen a lot of code needs to 
change.

My suggestion is as follows; require  property for single-argument 
setters *only*. Make the silly writeln = 13; go away, but keep the "a b 
c".split;. This way, there can be no confusion about  property, and most 
code will go unchanged.

I hope this was not too late a suggestion. :)
Jun 24 2010
next sibling parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
Pelle wrote:

 As heard around these parts, a lot of people want property-style
 function calls to require the function to be declared with  property,
 like this:
 
  property foo(); //getter
  property foo(int); //setter
 
 foo; //getter
 foo = 13; //setter
 
 While this seems quite reasonable, in practice I and others feel this
 leads to confusion, especially the getter part. Mostly when the getter
 has no setter counterpart. D also lets us call no-argument functions
 without parentheses today, so for this to happen a lot of code needs to
 change.
 
 My suggestion is as follows; require  property for single-argument
 setters *only*. Make the silly writeln = 13; go away, but keep the "a b
 c".split;. This way, there can be no confusion about  property, and most
 code will go unchanged.
 
 I hope this was not too late a suggestion. :)

I thought that the whole point of property was that it enabled the property-style function calls with no parens and that functions not labeled with property had to be called with parens. - Jonathan M Davis
Jun 24 2010
parent reply Pelle <pelle.mansson gmail.com> writes:
On 06/24/2010 10:25 PM, Jonathan M Davis wrote:
 Pelle wrote:

 As heard around these parts, a lot of people want property-style
 function calls to require the function to be declared with  property,
 like this:

  property foo(); //getter
  property foo(int); //setter

 foo; //getter
 foo = 13; //setter

 While this seems quite reasonable, in practice I and others feel this
 leads to confusion, especially the getter part. Mostly when the getter
 has no setter counterpart. D also lets us call no-argument functions
 without parentheses today, so for this to happen a lot of code needs to
 change.

 My suggestion is as follows; require  property for single-argument
 setters *only*. Make the silly writeln = 13; go away, but keep the "a b
 c".split;. This way, there can be no confusion about  property, and most
 code will go unchanged.

 I hope this was not too late a suggestion. :)

I thought that the whole point of property was that it enabled the property-style function calls with no parens and that functions not labeled with property had to be called with parens. - Jonathan M Davis

Also to disable writeln = 13; But I want to keep paren-less calls and remove silly call-as-assignment, except for when marked as to make sense.
Jun 24 2010
parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
Pelle wrote:

 Also to disable writeln = 13;
 
 But I want to keep paren-less calls and remove silly call-as-assignment,
 except for when marked as to make sense.

As I understand it, the whole point of properties in general is that they allow you to exchange public member variables and functions without changing code that uses the class. By being able to change a public member variable into a function, you can do things later on like add code to validate what you're setting the variable to or you can make the property computed instead of having an actual member variable for that data. The fact that you can call all non-void single-arg functions and all void single-arg functions in D is purely a side-effect of the fact that property syntax was originally enabled in D by simply allowing all functions that matched the syntax of a property function - i.e. void single-arg and non- void no-arg functions - to be called without parens. This lead to people calling non-property functions as if they were properties - writeln being a prime example. Other than legacy, code I see _0_ benefit to allowing non-property functions to be called as if they were properties. They aren't properties and shouldn't be treated that way. Now, a programmer is free to use property as they please in the code and can abuse it just like any other part of the language, but the whole point of being able to call functions without parens is in order to have property syntax for properties. I, for one, do _not_ think that non-property functions should be able to be called as if they were properties. - Jonathan M Davis
Jun 24 2010
parent reply Pelle <pelle.mansson gmail.com> writes:
On 06/24/2010 10:43 PM, Jonathan M Davis wrote:
 Other than legacy, code I see _0_ benefit to allowing non-property functions
 to be called as if they were properties. They aren't properties and
 shouldn't be treated that way. Now, a programmer is free to use  property as
 they please in the code and can abuse it just like any other part of the
 language, but the whole point of being able to call functions without parens
 is in order to have property syntax for properties. I, for one, do _not_
 think that non-property functions should be able to be called as if they
 were properties.

 - Jonathan M Davis

The problem lies within the definition of what a property is and is not, as well as can and cannot be. A benefit to the current situation is that fewer parentheses means less line noise, and prettier code.
Jun 24 2010
next sibling parent div0 <div0 users.sourceforge.net> writes:
On 24/06/2010 22:15, Pelle wrote:
 A benefit to the current situation is that fewer parentheses means less
 line noise, and prettier code.

That's only in your opinion and this discussion has been done to far beyond death. For gods sake just stop. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Jun 24 2010
prev sibling parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
My apologies if this ends up being sent twice. I'm having problems with my 
client at the moment.

On Thursday, June 24, 2010 14:15:22 Pelle wrote:
 On 06/24/2010 10:43 PM, Jonathan M Davis wrote:
 Other than legacy, code I see 0 benefit to allowing non-property
 functions to be called as if they were properties. They aren't
 properties and shouldn't be treated that way. Now, a programmer is free
 to use  property as they please in the code and can abuse it just like
 any other part of the language, but the whole point of being able to
 call functions without parens is in order to have property syntax for
 properties. I, for one, do not think that non-property functions
 should be able to be called as if they were properties.
 
 - Jonathan M Davis

The problem lies within the definition of what a property is and is not, as well as can and cannot be. A benefit to the current situation is that fewer parentheses means less line noise, and prettier code.

I really didn't think that there was much of question on that, but I guess that I was wrong. Everywhere that I've seen properties discussed, properties are values that could be either public member variables or have private member variables with getters and setters - the one extension being that that rather than having the property being stored in a member variable, it could be calculated (such as empty being calculated from size rather than stored separately). If it doesn't make sense for the property to be replaced with a getter function (if it's a readable property) and/or setter function (if it's a writeable property), then it's not a property. writeln() isn't a property because it makes no sense to replace it with a getter or setter. The same goes for save() or popFront() on a range. However, things like length() and empty() are properties because they could be replaced with functions like getLength() and isEmpty(). I really think that the main problem here is that any function that looked like property could previously be called like a property. Now, with the property syntax, it becomes a matter of choice of the programmer. They are free to label properties with property or mislabel non-properties with property. There probably are a few functions out there where it would be unclear as to whether they should be a property or not, but for the most part, I don't see why there should be any confusion. Properties are basically a way to make getters and setters look like public member variables. - Jonathan M Davis
Jun 24 2010
next sibling parent Jonathan M Davis <jmdavisProg gmail.com> writes:
Jonathan M Davis wrote:

 writeln() isn't a property because it makes no sense to replace it with a
 getter or setter. The same goes for save() or popFront() on a range.
 However, things like length() and empty() are properties because they
 could be replaced with functions like getLength() and isEmpty().

Okay. After some thought, I recant what I said about save (but not the rest). It's _is_ a property (or at least a pseudo-property), but it's poorly named (as Steven has been saying). Personally, I would say that for a function to make sense as a property, you should be able to rewrite its name as a getter or setter and have it make sense - e.g. length as getLength(). save doesn't work as getSave(), so it's poorly named. Something like copy - therefore getCopy() as a getter - would make more sense. dup would be even better, but I'm not sure that that would work given how dup is already used with arrays. In any case, I'd say it's a pseudo-property rather than a property because it really isn't a property of the range. It's returning a copy of the range rather than any property of that range. It would make no sense whatsoever for save to be a member variable of the range. But it _does_ make sense to have a getter which returns a copy, so save is definitely one of those weird cases where something is a property, but it isn't. In this case, Andrei appears to have chosen for it to be a property. - Jonathan M Davis
Jun 24 2010
prev sibling parent reply Max Samukha <spambox d-coding.com> writes:
On 06/25/2010 12:51 AM, Jonathan M Davis wrote:

 writeln() isn't a property because it makes no sense to replace it with a
 getter or setter. The same goes for save() or popFront() on a range.
 However, things like length() and empty() are properties because they could
 be replaced with functions like getLength() and isEmpty().

I don't think the rule applies universally. For example, .NET is full of functions starting with Set/Get that are not properties because they perform complex/lengthy computations or for some other washy reason.
Jun 24 2010
next sibling parent Jonathan M Davis <jmdavisProg gmail.com> writes:
Max Samukha wrote:

 On 06/25/2010 12:51 AM, Jonathan M Davis wrote:
 
 writeln() isn't a property because it makes no sense to replace it with a
 getter or setter. The same goes for save() or popFront() on a range.
 However, things like length() and empty() are properties because they
 could be replaced with functions like getLength() and isEmpty().

I don't think the rule applies universally. For example, .NET is full of functions starting with Set/Get that are not properties because they perform complex/lengthy computations or for some other washy reason.

Well, that means that they probably decided that not only do properties have to essentially be nicer getters and/or setters but that they have to be at least close to as efficient as getting or setting a public member variable - likely at minimum requiring that they be O(1). Also, there are functions - particularly for getters - where it makes sense to start them with get or set but where they really aren't properties of the object - rather the object is fetching whatever you asked it to get rather than returning the value of one of its member variables. Still, there are bound to be cases that are a bit fuzzy. save is one example that we have in D already (aside from the naming issue). Naming functions can be a hard thing to do. But I think that the basic idea that a property is effectively a fancy member variable is the basic grounds for choosing whether a particular function counts as a property or not. As with many things, however, it's up to the programmer to decide exactly what to do in a given situation, and applying rules too strictly can cause other problems. - Jonathan M davis
Jun 24 2010
prev sibling parent Jussi Jumppanen <jussij zeusedit.com> writes:
Max Samukha Wrote:

 I don't think the rule applies universally. For example, .NET is full of 
 functions starting with Set/Get that are not properties because they 
 perform complex/lengthy computations or for some other washy reason.

In .Net it is generally not a good idea to write a getter property that changes the object in any way (i.e. they should be written as pure read only). And why is that you ask? Because when you watch a object in the debugger the debugger extracts the object debug information by calling the these getter properties. So if the object properties are written badly and change the object, then by just adding that object to a watch window or hovering over it with the mouse will result in the corruption of the object. This can make for some very interesting debugging.
Jun 24 2010
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 24 Jun 2010 16:21:37 -0400, Pelle <pelle.mansson gmail.com> wrote:

 As heard around these parts, a lot of people want property-style  
 function calls to require the function to be declared with  property,  
 like this:

  property foo(); //getter
  property foo(int); //setter

 foo; //getter
 foo = 13; //setter

 While this seems quite reasonable, in practice I and others feel this  
 leads to confusion, especially the getter part. Mostly when the getter  
 has no setter counterpart. D also lets us call no-argument functions  
 without parentheses today, so for this to happen a lot of code needs to  
 change.

How is this confusing? It's a read-only property. They are used in countless design patterns. Furthermore, how will allowing any no-arg function to be called without parentheses *not* lead to confusion? e.g. struct File { bool open() {...} } File f; if(f.open) // looks to me like a property saying whether f is open if(f.open()) // looks to me like a function opening f. Like it or not, the parentheses are part of the name of the function/property, and to not be able to control whether parens are used as an author of said function/property leaves me to answer unending requests for changes to the API, such as "why don't you change open to openFile to make it clear that it's a function." Hey, look, we're back to Java's getX and setX, but in reverse! Wheeee! With property, I don't have to do that, because it's very obvious that since open requires parentheses, it is effecting an action on f.
 My suggestion is as follows; require  property for single-argument  
 setters *only*. Make the silly writeln = 13; go away, but keep the "a b  
 c".split;. This way, there can be no confusion about  property, and most  
 code will go unchanged.

property is much better than the current situation, even for getters. C#, python, I'm sure other languages, have worked fine for years with explicit properties, this debate is non-existent there. In a couple months after property has been enforcing the parens rule, nobody will think about this debate any more. The only pain is in undoing the hack that is D's current properties. -Steve
Jun 24 2010
parent reply Pelle <pelle.mansson gmail.com> writes:
On 06/24/2010 10:45 PM, Steven Schveighoffer wrote:
 How is this confusing? It's a read-only property. They are used in
 countless design patterns.

The confusion isn't their existence, but rather deciding what is a property and what is not.
 Furthermore, how will allowing any no-arg function to be called without
 parentheses *not* lead to confusion?

Note that many languages never require parentheses, and they're not particularly confused.
 struct File
 {
 bool open() {...}
 }

 File f;

 if(f.open) // looks to me like a property saying whether f is open
 if(f.open()) // looks to me like a function opening f.

 Like it or not, the parentheses are part of the name of the
 function/property, and to not be able to control whether parens are used
 as an author of said function/property leaves me to answer unending
 requests for changes to the API, such as "why don't you change open to
 openFile to make it clear that it's a function." Hey, look, we're back
 to Java's getX and setX, but in reverse! Wheeee!

 With  property, I don't have to do that, because it's very obvious that
 since open requires parentheses, it is effecting an action on f.

I feel this is a naming issue, not a property-issue. Is the empty() of a range a property? Is the save() a property? It's just up to anyone to guess and argue either way.
  property is much better than the current situation, even for getters.
 C#, python, I'm sure other languages, have worked fine for years with
 explicit properties, this debate is non-existent there.

And paren-less function calls have worked fine for years in a bunch of other languages. This debate is non-existent there as well.
 In a couple months after  property has been enforcing the parens rule,
 nobody will think about this debate any more. The only pain is in
 undoing the hack that is D's current properties.

 -Steve

The only hack is that calling by assigning works for all single-arg functions.
Jun 24 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:
 How about we get rid of case-sensitivity, so people who like to use all  
 caps can have their say in how they call your functions.  Does it make any  
 sense?

Case-insensitive languages make sense. In many natural languages written words usually mean the same thing regardless their case. In the same way, the "hello" word written with a blue pen means the same thing as "hello" written with a red pen. They are the same word. The same is true if you write "HELLO" or "Hello" or "hello", case is seen as the color of text, it doesn't change text meaning. For people that learn their first programming language I think that a caseless language is simpler to learn, because they need to learn one thing less (that writing "for" and "For" is not the same keyword as in the natural languages they know already). In practice in Pascal-like languages you don't write with random case like rEpEAT UNtiL, you keep an uniform case, it's a style, like Repeat or repeat in the whole program. Newbie Delphi programmers sometimes switch case in a single program. Case-insensitive languages are not so bad (more modern languages have invented ways to use the case in structured ways, so if you turn D into a case-insensitive language you will probably have some troubles. To avoid such troubles you need a language that is designed from the start to be case-insensitive). Bye, bearophile
Jun 24 2010
parent bearophile <bearophileHUGS lycos.com> writes:
But programmers often use casing differences to use more than one word to
describe a symbol.<

Only programmers of case-sensitive languages :-) In Delphi programmers just don't do that, there are plenty of other strings available in their universe :-)
theResetButton vs. thereSetButtOn look like two different things to me (one is
a button to reset something, and the other, well I guess it might be a chair?).
 Doesn't change the meaning to the compiler, but the human reading it is
confused.<

Humans can be confused a bit, right (but those humans are mostly the ones trained by case-sensitive languages usage). This is why all serious programmers of case-insensitive languages adopt a style and write identifiers in a uniform way, just like you put braces and indents in a standard way in your D programs, to help readability. The end result is that Delphi programs are not harder to read than D programs :-) Probably they are a bit simpler to read than C programs.
Same for omitting parentheses or including them to call the same function.<

If you are trained to write lot of code in Haskell then you probably don't miss parentheses so much. I agree that in D it's better to keep them on default. But it's not an universal thing. Bye, bearophile
Jun 25 2010
prev sibling next sibling parent reply Pelle <pelle.mansson gmail.com> writes:
On 06/24/2010 11:38 PM, Steven Schveighoffer wrote:
 This is why you are confused --  property *is* a naming issue. The
 difference between the hackish D current syntax and the sane  property
 syntax is that in hackish D, the caller gets to decide how to name the
 function, which doesn't make any sense.

 And the problem is precisely that it's anyone's guess. It should be up
 to the author of the structure. It should *not* be up to the user of the
 struct to 'guess'.

 How about we get rid of case-sensitivity, so people who like to use all
 caps can have their say in how they call your functions. Does it make
 any sense? How about we allow spanish translations of english terms to
 be used? How about just unambiguous prefixes? Any naming issue should be
 decided by the author of the function so that 1) it's consistent
 everywhere it's used and 2) the author is free to imply a meaning
 without resorting to overly verbose text. To allow otherwise causes way
 more confusion than some author who can't decide on whether something is
 a property or not. I very seldom run into cases where the name of the
 function is obvious, but whether to make it a property or not isn't. I
 always consider the property/no-property question when deciding the
 name. Empty is a perfect example -- property through and through.

 Save is not as obvious, but that's because the author decided the name
 without considering whether it should be a property. If it should be
 considered a property, it should be a noun (not a hard rule, but it
 makes more sense that way). I'd say something like 'copy' would look
 better as a property. But IMO, save provides almost no utility so that
 leads to it being hard to name. Blaming property syntax is not the way out.

Your argument seems to stem from the idea that property is part of the name of a function, and that the () indicates some mutative action upon an object. Well, liking it or not I do not agree about the naming part, I see it more in the league of coding style and indentation. I totally allow users of my code to decide their variable names and indentation style. We always have constness and/or purity to imply lack of mutation. Is split a property? It doesn't mutate a string, and totally could be an instance variable for every given string, but isn't. It doesn't really feel property-like, but writing "a b c".split without parentheses works better than with them.
Jun 24 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Pelle:
 Is split a property? It doesn't mutate a string, and totally could be an 
 instance variable for every given string, but isn't. It doesn't really 
 feel property-like, but writing "a b c".split without parentheses works 
 better than with them.

"a b c".split() is better. Bye, bearophile
Jun 24 2010
prev sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Steven Schveighoffer Wrote:

 Save is not as obvious, but that's because the author decided the name  
 without considering whether it should be a property.  If it should be  
 considered a property, it should be a noun (not a hard rule, but it makes  
 more sense that way).  I'd say something like 'copy' would look better as  
 a property.  But IMO, save provides almost no utility so that leads to it  
 being hard to name.  Blaming property syntax is not the way out.

Personally I think of a property as something that makes sense for you to "get" something and to "set" something. Sure you might provide only one of those options to control interaction, but I have a hard time seeing 'copy' as a property since you wouldn't want to write: a.copy = "this is a copy of a"; Now, on the other side of things, calling functions without parenthesis. I don't have many issues with this except these points, and neither of these have been resolved with the current situation. * Allows ambiguous-looking code: int delegate() foo() { return delegate int(){ return 5; }; } // Is this an int or a delegate? auto x = foo(); // Is this a reference to foo, or a reference to the delegate returned by foo? auto y = &foo; * Cannot use +=, -=, etc.
Jun 24 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 24 Jun 2010 17:11:08 -0400, Pelle <pelle.mansson gmail.com> wrote:

 On 06/24/2010 10:45 PM, Steven Schveighoffer wrote:
 How is this confusing? It's a read-only property. They are used in
 countless design patterns.

The confusion isn't their existence, but rather deciding what is a property and what is not.

That is an addendum to deciding the name of the function. Property-or-not is a name decision, and is as arbitrary as deciding a good name for a function.
 Furthermore, how will allowing any no-arg function to be called without
 parentheses *not* lead to confusion?

Note that many languages never require parentheses, and they're not particularly confused.

D is of C lineage, and as such, should follow C's conventions -- parens for functions, no parens for properties.
 struct File
 {
 bool open() {...}
 }

 File f;

 if(f.open) // looks to me like a property saying whether f is open
 if(f.open()) // looks to me like a function opening f.

 Like it or not, the parentheses are part of the name of the
 function/property, and to not be able to control whether parens are used
 as an author of said function/property leaves me to answer unending
 requests for changes to the API, such as "why don't you change open to
 openFile to make it clear that it's a function." Hey, look, we're back
 to Java's getX and setX, but in reverse! Wheeee!

 With  property, I don't have to do that, because it's very obvious that
 since open requires parentheses, it is effecting an action on f.

I feel this is a naming issue, not a property-issue. Is the empty() of a range a property? Is the save() a property? It's just up to anyone to guess and argue either way.

This is why you are confused -- property *is* a naming issue. The difference between the hackish D current syntax and the sane property syntax is that in hackish D, the caller gets to decide how to name the function, which doesn't make any sense. And the problem is precisely that it's anyone's guess. It should be up to the author of the structure. It should *not* be up to the user of the struct to 'guess'. How about we get rid of case-sensitivity, so people who like to use all caps can have their say in how they call your functions. Does it make any sense? How about we allow spanish translations of english terms to be used? How about just unambiguous prefixes? Any naming issue should be decided by the author of the function so that 1) it's consistent everywhere it's used and 2) the author is free to imply a meaning without resorting to overly verbose text. To allow otherwise causes way more confusion than some author who can't decide on whether something is a property or not. I very seldom run into cases where the name of the function is obvious, but whether to make it a property or not isn't. I always consider the property/no-property question when deciding the name. Empty is a perfect example -- property through and through. Save is not as obvious, but that's because the author decided the name without considering whether it should be a property. If it should be considered a property, it should be a noun (not a hard rule, but it makes more sense that way). I'd say something like 'copy' would look better as a property. But IMO, save provides almost no utility so that leads to it being hard to name. Blaming property syntax is not the way out.
  property is much better than the current situation, even for getters.
 C#, python, I'm sure other languages, have worked fine for years with
 explicit properties, this debate is non-existent there.

And paren-less function calls have worked fine for years in a bunch of other languages. This debate is non-existent there as well.

Do those languages allow parentheses? Do they allow calling functions with parameters without parentheses? If the convention is parentheses are forbidden or always optional, it's less confusion, because you can't assume anything from the parentheses or lack thereof. I don't see how we are better off not being able to use parentheses to disambiguate semantic meaning. -Steve
Jun 24 2010
prev sibling next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 24 Jun 2010 16:21:37 -0400, Pelle <pelle.mansson gmail.com> wrote:

 As heard around these parts, a lot of people want property-style  
 function calls to require the function to be declared with  property,  
 like this:

  property foo(); //getter
  property foo(int); //setter

 foo; //getter
 foo = 13; //setter

 While this seems quite reasonable, in practice I and others feel this  
 leads to confusion, especially the getter part. Mostly when the getter  
 has no setter counterpart. D also lets us call no-argument functions  
 without parentheses today, so for this to happen a lot of code needs to  
 change.

 My suggestion is as follows; require  property for single-argument  
 setters *only*. Make the silly writeln = 13; go away, but keep the "a b  
 c".split;. This way, there can be no confusion about  property, and most  
 code will go unchanged.

 I hope this was not too late a suggestion. :)

writeln = 13; doesn't compile, just so you know. ;)
Jun 24 2010
parent Pelle <pelle.mansson gmail.com> writes:
On 06/25/2010 03:00 AM, Robert Jacques wrote:
 writeln = 13; doesn't compile, just so you know. ;)

Then something has probably changed :) writeln!int = 13 compiles, however. And printf = "123\n", and so on.
Jun 25 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 24 Jun 2010 17:58:39 -0400, bearophile <bearophileHUGS lycos.com>  
wrote:

 Steven Schveighoffer:
 How about we get rid of case-sensitivity, so people who like to use all
 caps can have their say in how they call your functions.  Does it make  
 any
 sense?

Case-insensitive languages make sense. In many natural languages written words usually mean the same thing regardless their case. In the same way, the "hello" word written with a blue pen means the same thing as "hello" written with a red pen. They are the same word. The same is true if you write "HELLO" or "Hello" or "hello", case is seen as the color of text, it doesn't change text meaning.

But programmers often use casing differences to use more than one word to describe a symbol. theResetButton vs. thereSetButtOn look like two different things to me (one is a button to reset something, and the other, well I guess it might be a chair?). Doesn't change the meaning to the compiler, but the human reading it is confused. Same for omitting parentheses or including them to call the same function. -Steve
Jun 25 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 24 Jun 2010 18:24:55 -0400, Pelle <pelle.mansson gmail.com> wrote:

 On 06/24/2010 11:38 PM, Steven Schveighoffer wrote:
 This is why you are confused --  property *is* a naming issue. The
 difference between the hackish D current syntax and the sane  property
 syntax is that in hackish D, the caller gets to decide how to name the
 function, which doesn't make any sense.

 And the problem is precisely that it's anyone's guess. It should be up
 to the author of the structure. It should *not* be up to the user of the
 struct to 'guess'.

 How about we get rid of case-sensitivity, so people who like to use all
 caps can have their say in how they call your functions. Does it make
 any sense? How about we allow spanish translations of english terms to
 be used? How about just unambiguous prefixes? Any naming issue should be
 decided by the author of the function so that 1) it's consistent
 everywhere it's used and 2) the author is free to imply a meaning
 without resorting to overly verbose text. To allow otherwise causes way
 more confusion than some author who can't decide on whether something is
 a property or not. I very seldom run into cases where the name of the
 function is obvious, but whether to make it a property or not isn't. I
 always consider the property/no-property question when deciding the
 name. Empty is a perfect example -- property through and through.

 Save is not as obvious, but that's because the author decided the name
 without considering whether it should be a property. If it should be
 considered a property, it should be a noun (not a hard rule, but it
 makes more sense that way). I'd say something like 'copy' would look
 better as a property. But IMO, save provides almost no utility so that
 leads to it being hard to name. Blaming property syntax is not the way  
 out.

Your argument seems to stem from the idea that property is part of the name of a function, and that the () indicates some mutative action upon an object.

Not exactly. I think () implies a function where no () implies a property. Mutation is *not* implied in (). What a function or a property consists of is all open to interpretation. Generally it's assumed that a getter property gets a value from the object, and a setter sets a value, and a function can do whatever it wants (mutation or otherwise). But what should not be open to interpretation is whether something is a property or a function. The key here is the *author* gets to decide the interpretation, so any usage of his code is consistent.
 Well, liking it or not I do not agree about the naming part, I see it  
 more in the league of coding style and indentation. I totally allow  
 users of my code to decide their variable names and indentation style.

This is not about allowing users to decide their variable names, it's about not letting users decide *your* variable names. If I build a struct or class, I want it's usage to be well-defined and consistent.
 We always have constness and/or purity to imply lack of mutation.

 Is split a property? It doesn't mutate a string, and totally could be an  
 instance variable for every given string, but isn't. It doesn't really  
 feel property-like, but writing "a b c".split without parentheses works  
 better than with them.

I disagree, I think "a b c".split() looks better. But it should be up to the author of split, if he thinks it's a property, then so be it, we will all use it as a property. -Steve
Jun 25 2010
prev sibling parent reply "Mike James" <foo bar.com> writes:
"Pelle" <pelle.mansson gmail.com> wrote in message 
news:i00ejm$2kii$1 digitalmars.com...
 As heard around these parts, a lot of people want property-style function 
 calls to require the function to be declared with  property, like this:

  property foo(); //getter
  property foo(int); //setter

 foo; //getter
 foo = 13; //setter

 While this seems quite reasonable, in practice I and others feel this 
 leads to confusion, especially the getter part. Mostly when the getter has 
 no setter counterpart. D also lets us call no-argument functions without 
 parentheses today, so for this to happen a lot of code needs to change.

 My suggestion is as follows; require  property for single-argument setters 
 *only*. Make the silly writeln = 13; go away, but keep the "a b c".split;. 
 This way, there can be no confusion about  property, and most code will go 
 unchanged.

 I hope this was not too late a suggestion. :)

Why not extend property further (a la objectpascal)... property T PropertyName get _propval set _propval; would generate the equivalent of: T _propval; property { T PropertyName() { return _propval; } T PropertyName(T aval) { return _propval = aval; } } or e.g. property T PropertyName get _propval set MySetValFunc; and provide the required setter function: T MySetValFunc(T myVal) { _propval = myVal; // do something with _propval return _propval; } -=mike=-
Jun 26 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Mike James:
 Why not extend  property further (a la objectpascal)...
 
  property T PropertyName  get _propval  set _propval;

Several people have suggested something related. Walter is not interested so far, I think. Bye, bearophile
Jun 26 2010