On Thu, 03 Mar 2011 16:27:37 -0500, Jonathan M Davis <jmdavisp...@gmx.com>
wrote:
On Thursday, March 03, 2011 12:32:44 kenji hara wrote:
It seems to me that you think only combination of member-variable like
property and UFCS.
My suggestion is consider global-variable like property as well.
example:
@property int global_var(){...} // getter, int n = global_var;
@property void global_var(int n){...} // setter, global_var = 10;
I think that global variable like setter function and member-variable
like getter function occur ambiguity.
Getter and Setter are the opposite meaning.
I'd strongly argue that global/module properties make no sense. What are
they a
property of? The module? The whole idea with properties in the first
place was to
be an abstraction of member variables. And since you really shouldn't be
using
mutable global/module variables anyway, the benefit of such a "property"
is
already limited. And if they cause ambiguity (as they obviously do),
then that's
one more reason to disallow them.
I think global properties are certainly valid. You can have a global
field, why not a global property?
The classic example is a singleton:
class Singleton
{
private this() {} // disable public construction
private Singleton _instance;
@property public static Singleton instance() {if(!_instance) _instance
= new Singleton; return _instance;}
}
Note that instance has no 'this' pointer. However, it obviously does not
have the ambiguities of UFC properties. However, I find the statement
that a property must be a member variable very incorrect.
I am sure there are good use cases for global (TLS) variables that are
properties. In fact, I use one in druntime. The LRU cache for array
appending is a per-thread array, and it *must* be allocated outside any
scannable location (not in TLS or GC heap). Therefore, I malloc it.
However, I malloc it on the first append. But this is hidden by a
property.
The main reason for doing it this way is because originally it was stored
in TLS as a fixed-size array. However, that meant any cached memory
blocks that were appended to would be kept in memory by the cache. I used
the fixed array directly in many places in the file, so the easiest change
was to make it a property. It works quite well actually. If we can ever
mark sections of TLS as non-scannable, then I can easily change it back
from a property to a field.
See
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d#L382
-Steve
