Uniform Function Call Syntax(UFCS) and @property

Jonathan M Davis jmdavisProg at gmx.com
Thu Mar 3 13:56:45 PST 2011


On Thursday, March 03, 2011 13:44:18 Steven Schveighoffer wrote:
> On Thu, 03 Mar 2011 16:27:37 -0500, Jonathan M Davis <jmdavisProg at 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/lifet
> ime.d#L382

Conceptually, a property makes no sense unless it's a property _of_ something. 
I'd argue that C# (which has properties) doesn't have global properties, but it 
doesn't even have global variables. It doesn't have static (class) properties 
though. Regardless, while syntactically, it might be beneficial in rare cases to 
use property syntax with a global variable, it violates the concept.

So, I'm against the idea regardless, but if allowing global properties results 
in ambiguities that would require additional syntax to make it work, then I'm 
that much more opposed to allowing it.

- Jonathan M Davis


More information about the Digitalmars-d mailing list