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

"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

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

"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

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

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

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

"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

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