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

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

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

Not anytime soon, sorry.

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

"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

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

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

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
>

> 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