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

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

"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

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

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

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

DeadCow wrote:
> It hides the fact that there's actions underneath : It looks like a basic
> 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 very convenient technique. It's abstraction over storage. If class designer is sane, it doesn't requiere to understand more, it just allows to carefully hide implementation details. I'm still thinking in Properties, so with C++ i still have to remember each time:

 - now, this property here - is it acessed as a field, or through methods?
 - if it involves methods, are the methods only for writing, only for reading (leaving the other to the field), or for both?
 - what it this particular libraries' convention on getter/setter method naming?

What it requieres us to remember, is not about "understanding", but 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 property in the future without changing the code. There are various reasons to switch to properties, which all boil down to abstraction over storage:

 - the library hierarchy has grown, and derived classes need to store data in a physically different manner than the base class;
 - it turns out to be more efficient to store data in a less staightforward manner, and properties let you do this change in the library without bugging the application programmer and asking him of forgiving. :))))))

Array acess operator should also be a sort of property.

I hope to have changed your mind.

-eye

"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

> I hope to have changed your mind.

You said it better than I could. :)

"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

"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