On 03/05/2011 03:50 AM, Michel Fortin wrote:
On 2011-03-04 13:04:59 -0500, Jim <bitcir...@yahoo.com> said:
Jonathan M Davis Wrote:
On Friday 04 March 2011 04:59:14 David Nadlinger wrote:
On 3/3/11 10:27 PM, Jonathan M Davis wrote:
I'd strongly argue that global/module properties make no sense. What are
they a property of? The module?
You could as well say: I'd strongly argue that global/module variables
make no sense. What are they a variable of? The module?
In my opinion, allowing global variables but not global properties just
creates yet another unneeded special case.
I see no special case or inconsistency. The original idea behind a property (as
I understand it) is to abstract member variables so that you can easily switch
between having a public member variable and having a public member function
without having to change code. The term property implies that it is a property
or attribute of whatever it's on. A global variable or a local variable or any
kind of variable not on a class or struct is free-floating and not a
property or
attribute of anything. How many languages which have properties have them on
_anything_ other than objects?
I was surprised that anyone would suggest that @property could be used on
anything other than a class or struct's member function. I strongly suspect
that
the main reason that anyone is thinking that way is because properties in D
grew
out of being able to call pretty much any old function without parens as
long as
it had no parameters instead of based on the concept of properties to begin
with
as it likely would have been in other languages.
- Jonathan M Davis
Let's talk about accessors instead of properties because we are talking about
the functions, right, not the storage per se?
@getter, @setter as proposed by Michel Fortin.
Actually, there's a big drawback in having separate @getter and @setter
attributes: grouping functions under one attribute declaration like this
becomes impractical:
@property {
int length();
void length(int);
int capacity();
void capacity(int);
}
This let me think at the actual functionality provided by the so-called
property feature. The following is more or less thinking out loud:
* An implicite getter allows
1. calling a method & running computations while letting think it's just
data member access. I find this bad. The good point is a change in
implementation, from data to method member, won't break code, *if and only if*
the new feature does not require any param (!). Even then, silently adding a
method call & possibly costly computation is imo bad.
2. Implementing a setter for 4.
* An implicite setter allows:
3. Implementing a getter for 1.
4. Performing effects which are a logical consequence of the data member
change. Eg "p.x = 1;" would actually /move/ p. I find this bad: there should be
a move method, and a read-only x data member.
* A getter without setter allows:
5. Read-only data members (to the price of language complication & a method
call).
Finally, I think what we actually need is a read-only qualifier for data
members. (E basta!)
Denis
--
_________________
vita es estrany
spir.wikidot.com
