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.   

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.

 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
parent reply "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.

 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
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 reply "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
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
next sibling 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 "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 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 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 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