www.digitalmars.com         C & C++   DMDScript  

D - Static properties

reply "Matthew Wilson" <matthew stlsoft.org> writes:
Are static properties going to be available?

e.g. (taking into account that the property syntax is invented on the spot)

class Y
{}

class X
{
private:
  X();

public:
  static property Y1
  {
    Y get ()
    {
      return sm_Y1;
    }
  }
  static property Y2
  {
    Y get ()
    {
      return sm_Y2;
    }
  }

private:
  static Y sm_Y1;
  static Y sm_Y2;
}
Aug 19 2003
next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
And use it like so: ?

if (X.Y1 == X.Y2) { foo(); }

Sean

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bhv3sl$11iq$1 digitaldaemon.com...
 Are static properties going to be available?

 e.g. (taking into account that the property syntax is invented on the

 class Y
 {}

 class X
 {
 private:
   X();

 public:
   static property Y1
   {
     Y get ()
     {
       return sm_Y1;
     }
   }
   static property Y2
   {
     Y get ()
     {
       return sm_Y2;
     }
   }

 private:
   static Y sm_Y1;
   static Y sm_Y2;
 }

Aug 20 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Not sure what you mean, but the thing I'm doing at the moment is a registry
API, in which the Registry class looks like

class Registry
{
    static this()
    {
        sm_keyClassesRoot       = new Key(DupKey(HKEY_CLASSES_ROOT));
        sm_keyCurrentUser       = new Key(DupKey(HKEY_CURRENT_USER));
        sm_keyLocalMachine      = new Key(DupKey(HKEY_LOCAL_MACHINE));
        sm_keyUsers             = new Key(DupKey(HKEY_USERS));
        sm_keyPerformanceData   = new Key(DupKey(HKEY_PERFORMANCE_DATA));
        sm_keyCurrentConfig     = new Key(DupKey(HKEY_CURRENT_CONFIG));
        sm_keyDynData           = new Key(DupKey(HKEY_DYN_DATA));
    }

private:
    this();

public:
    /// Returns the root key for the HKEY_CLASSES_ROOT hive
    static Key  get_ClassesRoot()       {   return
ClassesRoot;       }
    /// Returns the root key for the HKEY_CURRENT_USER hive
    static Key  get_CurrentUser()       {   return
CurrentUser;       }
    /// Returns the root key for the HKEY_LOCAL_MACHINE hive
    static Key  get_LocalMachine()      {   return
yLocalMachine;      }
    /// Returns the root key for the HKEY_USERS hive
    static Key  get_Users()             {   return
             }
    /// Returns the root key for the HKEY_PERFORMANCE_DATA hive
    static Key  get_PerformanceData()   {   return
_keyPerformanceData;   }
    /// Returns the root key for the HKEY_CURRENT_CONFIG hive
    static Key  get_CurrentConfig()     {   return
eyCurrentConfig;     }
    /// Returns the root key for the HKEY_DYN_DATA hive
    static Key  get_DynData()           {   return
ata;           }

private:
    static Key  sm_keyClassesRoot;
    static Key  sm_keyCurrentUser;
    static Key  sm_keyLocalMachine;
    static Key  sm_keyUsers;
    static Key  sm_keyPerformanceData;
    static Key  sm_keyCurrentConfig;
    static Key  sm_keyDynData;
}


What I'd like is to be able to use it like

 Registry.ClassesRoot (which would return a Key)

rather than having to call

 Registry.get_ClassesRoot()

Seem desirable?

"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bhvdeq$1gaj$1 digitaldaemon.com...
 And use it like so: ?

 if (X.Y1 == X.Y2) { foo(); }

 Sean

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bhv3sl$11iq$1 digitaldaemon.com...
 Are static properties going to be available?

 e.g. (taking into account that the property syntax is invented on the

 class Y
 {}

 class X
 {
 private:
   X();

 public:
   static property Y1
   {
     Y get ()
     {
       return sm_Y1;
     }
   }
   static property Y2
   {
     Y get ()
     {
       return sm_Y2;
     }
   }

 private:
   static Y sm_Y1;
   static Y sm_Y2;
 }


Aug 20 2003
parent reply "DeadCow" <deadcow-remove-this free.fr> writes:
 What I'd like is to be able to use it like

  Registry.ClassesRoot (which would return a Key)

 rather than having to call

  Registry.get_ClassesRoot()

 Seem desirable?

Pure syntaxic sugar isn't ? -- Nicolas Repiquet
Sep 04 2003
next sibling parent "Achilleas Margaritis" <axilmar in.gr> writes:
"DeadCow" <deadcow-remove-this free.fr> wrote in message
news:bj7au3$8td$1 digitaldaemon.com...
 What I'd like is to be able to use it like

  Registry.ClassesRoot (which would return a Key)

 rather than having to call

  Registry.get_ClassesRoot()

 Seem desirable?

Pure syntaxic sugar isn't ? -- Nicolas Repiquet

Syntactic sugar is VERY important. When you go back at the code or another person looks at it, it makes a big difference.
Sep 04 2003
prev sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
No question. But it has no downside, so why not have it?

"DeadCow" <deadcow-remove-this free.fr> wrote in message
news:bj7au3$8td$1 digitaldaemon.com...
 What I'd like is to be able to use it like

  Registry.ClassesRoot (which would return a Key)

 rather than having to call

  Registry.get_ClassesRoot()

 Seem desirable?

Pure syntaxic sugar isn't ? -- Nicolas Repiquet

Sep 04 2003
parent reply "DeadCow" <deadcow-remove-this free.fr> writes:
"Matthew Wilson" <matthew stlsoft.org> a écrit dans le message news:
bj7em3$e37$1 digitaldaemon.com...
 No question. But it has no downside, so why not have it?

It hides the fact that there's actions underneath : It looks like a basic field but it's a method call. Key k = Registry.getClassesRoot(); Key k = Registry.ClassesRoot; Wich one perform a system call ? both ? Personally, it sounds like "less to type, more to understand". -- Nicolas Repiquet
Sep 04 2003
next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
 It hides the fact that there's actions underneath : It looks like a basic
 field but it's a method call.

Is that wrong? Isn't OO all about presenting a logical, rather than a physical, face to the world (of client code)? Anyway, in this case there is no significant code being masked. The static constructor for the Registry class creates the various root Key instances (and handles any failures there, as it should be), so the "call" to the property, or to the accessor method, simply returns the reference. In this instance, a read-only member would be appropriate, but D does not have final members. (At least I don't think it does!) Hence, a get-only (static) property is required. Also, it's possible that in a similar API, where security was being enforced, the property getter could conduct access checks, which would be kind of neat.
 Key k = Registry.getClassesRoot();
 Key k = Registry.ClassesRoot;

 Wich one perform a system call ? both ?

 Personally, it sounds like "less to type, more to understand".

 -- Nicolas Repiquet

Sep 04 2003
prev sibling parent reply Ilya Minkov <midiclub 8ung.at> writes:
 "Matthew Wilson" <matthew stlsoft.org> a =E9crit dans le message news:
 bj7em3$e37$1 digitaldaemon.com...
No question. But it has no downside, so why not have it?


DeadCow wrote:
 It hides the fact that there's actions underneath : It looks like a bas=

 field but it's a method call.

 Personally, it sounds like "less to type, more to understand".

If you ever worked with Delphi, you would know that this is really a=20 very convenient technique. It's abstraction over storage. If class=20 designer is sane, it doesn't requiere to understand more, it just allows = to carefully hide implementation details. I'm still thinking in=20 Properties, so with C++ i still have to remember each time: - now, this property here - is it acessed as a field, or through method= s? - if it involves methods, are the methods only for writing, only for=20 reading (leaving the other to the field), or for both? - what it this particular libraries' convention on getter/setter=20 method naming? What it requieres us to remember, is not about "understanding", but=20 about silly implementation-dependant facts. The properties solve this in = a most elegant manner. Implementation independancy also means, that what = in one library version is a plin field, may become a method-acessed=20 property in the future without changing the code. There are various=20 reasons to switch to properties, which all boil down to abstraction over = storage: - the library hierarchy has grown, and derived classes need to store=20 data in a physically different manner than the base class; - it turns out to be more efficient to store data in a less=20 staightforward manner, and properties let you do this change in the=20 library without bugging the application programmer and asking him of=20 forgiving. :)))))) Array acess operator should also be a sort of property. I hope to have changed your mind. -eye
Sep 04 2003
next sibling parent reply "DeadCow" <deadcow-remove-this free.fr> writes:
"Ilya Minkov" <midiclub 8ung.at> a écrit dans le message news:
bj8jju$23ic$1 digitaldaemon.com...

 I hope to have changed your mind.

Isn't an implicit getter/setter generation better ? class A { Int b; } A a = new A(); a.b( 1 ); // work automagicaly int i = a.b(); // too // or maybe setB & getB. a.b = 1 ; // direct access is forbiden int i = a.b; // too -- Nicolas Repiquet
Sep 04 2003
parent Ilya Minkov <webmaster midiclub.de.vu> writes:
DeadCow wrote:

 Isn't an implicit getter/setter generation better ?

Do we really have to uglify the world? :) Well, e.g. Sather does generate getters/setters for each field as well. Haven't seen anyone use them though - unless probably packaging them in a closure, to pass to some handler or somesuch... In D, this might lead to some conflict... since a Sather class is not an interface, but a D class is. -eye
Sep 05 2003
prev sibling next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
 I hope to have changed your mind.

You said it better than I could. :)
Sep 04 2003
prev sibling parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Ilya Minkov" <midiclub 8ung.at> ha scritto nel messaggio
news:bj8jju$23ic$1 digitaldaemon.com...
 I hope to have changed your mind.

You could have changed mine as well! :) But, being a Delphi fan (not in the "language holy war" sense, just because IMO it makes me write better code than any other language I've used), all I can say is that I confirm every word of your message. I'd even prefer the keyword "class" instead of "static" for static members... Ric
Sep 05 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
news:bj9d8f$8cr$1 digitaldaemon.com...
 "Ilya Minkov" <midiclub 8ung.at> ha scritto nel messaggio
 news:bj8jju$23ic$1 digitaldaemon.com...
 I hope to have changed your mind.

You could have changed mine as well! :) But, being a Delphi fan (not in

 "language holy war" sense, just because IMO it makes me write better code
 than any other language I've used), all I can say is that I confirm every
 word of your message. I'd even prefer the keyword "class" instead of
 "static" for static members...

 Ric

Wouldn't that conflict with syntax for nested classes? class A { private: class B {} // nested class class int C; // static member variable class B D; // now it's getting confusing... I guess this is a static member variable reference to a B class E {}F; // instance F of nested class E... does this kind of declaration even work in D? } Sean
Sep 05 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 Wouldn't that conflict with syntax for nested classes?

 class A
 {
 private:
     class B {}  // nested class
     class int C;  // static member variable
     class B D;  // now it's getting confusing... I guess this is a static
 member variable reference to a B
     class E {}F;  // instance F of nested class E... does this kind of
 declaration even work in D?
 }

Not wishing to be an irritant (believe me?), but that seems obvious, albeit unattractive to me. Notwithstanding that, Sean, I'm interested in your opinion on Properties, and Class/Static ones. Reason being is Walter's trying to pike on committing to Static Properties, and I'm trying to get a posse together. :)
Sep 05 2003
next sibling parent BenjiSmith <dlanguage xxagg.com> writes:
In article <bj9hel$eqe$1 digitaldaemon.com>, Matthew Wilson says...
 Walter's trying to pike on committing to Static Properties, and I'm
 trying to get a posse together. :)

Sign me up for that posse. I'd love to see static properties. Or, at the very least, a readonly attribute for public member variables. No...wait...give me static properties instead. --Benji
Sep 05 2003
prev sibling next sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bj9hel$eqe$1 digitaldaemon.com...
 Wouldn't that conflict with syntax for nested classes?

 class A
 {
 private:
     class B {}  // nested class
     class int C;  // static member variable
     class B D;  // now it's getting confusing... I guess this is a


 member variable reference to a B
     class E {}F;  // instance F of nested class E... does this kind of
 declaration even work in D?
 }

Not wishing to be an irritant (believe me?), but that seems obvious,

 unattractive to me.

If that last E/F declaration style still works in D, it seems like it would be hard to parse. Probably need a different keyword, as class is too problematic and static is overloaded too much already.
 Notwithstanding that, Sean, I'm interested in your opinion on Properties,
 and Class/Static ones. Reason being is Walter's trying to pike on

 to Static Properties, and I'm trying to get a posse together. :)

I'm with you. I want syntax sugar that makes method calls act like variables, whatever will allow me to 'simulate' a variable, just one that has possible actions on load and store, and can be changed later if necessary. I think it greatly aids maintainability, usability. Makes a codebase much more consistent. Gets rid of all the superfluous () everywhere. Sean
Sep 06 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
I didn't finish answering your question.

Static properties:  yes, I'd like to be able to simulate a variable
anywhere, not just as a class member.

Sean

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bj9hel$eqe$1 digitaldaemon.com...
 Notwithstanding that, Sean, I'm interested in your opinion on Properties,
 and Class/Static ones. Reason being is Walter's trying to pike on

 to Static Properties, and I'm trying to get a posse together. :)

Sep 06 2003
prev sibling parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Sean L. Palmer" <palmer.sean verizon.net> ha scritto nel messaggio
news:bj9fq8$chj$1 digitaldaemon.com...
 Wouldn't that conflict with syntax for nested classes?

 class A
 {
 private:
     class B {}  // nested class
     class int C;  // static member variable
     class B D;  // now it's getting confusing... I guess this is a static
 member variable reference to a B
     class E {}F;  // instance F of nested class E... does this kind of
 declaration even work in D?
 }

Oops... You're right! I take it back. Still, I don't think "static" is the right word to identify members common to all instances of a class. How about "common"? Wouldn't it make more sense, in spite of being a bit more to learn when switching from C / C++? Ric
Sep 05 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
 class A
 {
 private:
     class B {}  // nested class
     class int C;  // static member variable
     class B D;  // now it's getting confusing... I guess this is a


 member variable reference to a B
     class E {}F;  // instance F of nested class E... does this kind of
 declaration even work in D?
 }

Oops... You're right! I take it back.

Eeek! I misunderstood. I certainly don't want class to be used for the keyword static.
 Still, I don't think "static" is the
 right word to identify members common to all instances of a class. How

 "common"? Wouldn't it make more sense, in spite of being a bit more to

 when switching from C / C++?

 Ric

Sep 05 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
Not anytime soon, sorry.
Aug 27 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
We need 'em. We need 'em real bad.

phobos.win32.reg shall be thy reward, brave knight!

"Walter" <walter digitalmars.com> wrote in message
news:bik9hu$2phd$1 digitaldaemon.com...
 Not anytime soon, sorry.

Aug 29 2003
parent reply Ilya Minkov <midiclub tiscali.de> writes:
Matthew Wilson wrote:
 We need 'em. We need 'em real bad.

To be able to access properties without creating an object? What would this be actually good for? -eye
Sep 04 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Well, anything that is a property of something that is not an object. There
are unlimited possibilities. I'll give you one.

I'm writing a Win32 registry library for Phobos, that is waiting only for
foreach and static properties. The static properties are so that I can
declare, in the Registry class, properties (of type Key) that map to the
registry hives, e.g. ClassesRoot, LocalMachine.

Without static properties, we are forced to use static methods and members,
e.g. get_ClassesRoot(). There is no advantage, conceptual or practical, to
this way of doing things. With static properties, the advantages are both.
Conceptual: the ClassesRoot is an object, it's a Key, and it is a property
of Registry, clearly. Practical: less key-presses, and the code looks
clearer

 Registry.ClassesRoot;

vs

 Registry.get_ClassesRoot();

Properties are a (very nice, and very desirable) syntactic sugar for member
variables and their associated get and/or set methods. Static properties are
similarly analogous to static members and their get and/or set methods. I
can respect an argument against static properties only if every component of
such an argument equally applies to static members. Is that what you're
suggesting?


"Ilya Minkov" <midiclub tiscali.de> wrote in message
news:bj75nd$1hn$1 digitaldaemon.com...
 Matthew Wilson wrote:
 We need 'em. We need 'em real bad.

To be able to access properties without creating an object? What would this be actually good for? -eye

Sep 04 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
Matthew Wilson wrote:
 I can respect an argument against static properties only if every
 component of such an argument equally applies to static members. Is
 that what you're suggesting?

I wasn't suggesting anything. I was just curious. The example explains it. I think that static properties would perfectly fit the syntax model of propertes which is already in spec, so at least it doesn't make any sense to disable them. But i also think that properties/non-static methods should work, if they don't use (or carefully check for nil) the hidden "this" argument, thus being able to work either with or without a concrete object - which would also work in this case. Properties may probably stop people who are leaving the D community to join C#. -eye
Sep 04 2003
parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Ilya Minkov" <midiclub 8ung.at> ha scritto nel messaggio
news:bj8cr9$1qhc$1 digitaldaemon.com...
 Properties may probably stop people who are leaving the D community to
 join C#.

A good standard library woudn't hurt, either... Better yet, once we have a "finished" compiler and a standard library deserving its name (no offense intended to the work being done so far) there would be good reasons for people to switch from C# to D! a maybe-daydreaming Ric
Sep 05 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
One would hope so.

I'm very keen to finish off the Registry library to a professional level,
once the properties are there. Hopefully then I can submit it to be annealed
in the fire of the ng opinion, and then maybe it can serve as an example
(once you've all had your way and I've had to change it beyond recognition
<sheds a tear>).


"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
news:bj9d8g$8cr$2 digitaldaemon.com...
 "Ilya Minkov" <midiclub 8ung.at> ha scritto nel messaggio
 news:bj8cr9$1qhc$1 digitaldaemon.com...
 Properties may probably stop people who are leaving the D community to
 join C#.

A good standard library woudn't hurt, either... Better yet, once we have a "finished" compiler and a standard library deserving its name (no offense intended to the work being done so far) there would be good reasons for people to switch from C# to D! a maybe-daydreaming Ric

Sep 05 2003
prev sibling parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Walter" <walter digitalmars.com> ha scritto nel messaggio
news:bik9hu$2phd$1 digitaldaemon.com...
 Not anytime soon, sorry.

Aaargh!! Please, Walter, give us properties, including static ones. Just figure what a standard library could look like with and without them... and the work involved, should it be written before the language has properties and then adapted once it has them. I know (or can imagine) you have a schedule that would easily kill two or three normal programmers... but properties are among the things I like most in D's specs, and I just can't wait for them. Ric
Sep 01 2003
parent "Matthew Wilson" <dmd synesis.com.au> writes:
Yup, I just want to say again I want to see them implemented asap.

Keeping it on the walteradar ...


"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
news:biuvlp$ofh$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> ha scritto nel messaggio
 news:bik9hu$2phd$1 digitaldaemon.com...
 Not anytime soon, sorry.

Aaargh!! Please, Walter, give us properties, including static ones. Just figure what a standard library could look like with and without them...

 the work involved, should it be written before the language has properties
 and then adapted once it has them.

 I know (or can imagine) you have a schedule that would easily kill two or
 three normal programmers... but properties are among the things I like

 in D's specs, and I just can't wait for them.

 Ric

Sep 01 2003