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


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 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


 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 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=


ic

 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


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


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




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.


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


committing

 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


committing

 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




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.


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


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
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


-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



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


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



 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


 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...


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