On Sun, 12 Jun 2005 13:51:00 -0400, KUV <KUV_member@pathlink.com> wrote:
> Is there the way to make properties like Delphi, so that writing and
> reading
> this property is processed with different function and procedure.
>
Check out http://www.digitalmars.com/d/property.html and skip down to
"Class and Struct Properties".

Unknown W. Brackets wrote:
> A few questions:
>
> 1. What is the benefit this has over the current syntax?
Its more explicit, which I think Properties ought to be. The current syntax is cute, and
does provide the primary requisite for clean properties, which is the ability to be
seamless between fields and methods. Or in other words, to user code a property should
appear no different from a field.
> 2. How do you propose to deal with the problem of a single
> expression/identifier having multiple possible types (which you'll
> notice D avoids heavily)?
Its a good question. Maybe we could require that there be only one gettor, and that its
return type match the type of the property. Or even that it define that type, so that the
property itself actually has no type. The type of expressions which use it would then be
that of the gettor. I'll have to think on it.
> 3. Why do you have two (different) lines declaring the property?
That was a mistake... I typed that out right after getting out of bed, you see. :) I
actually made up the "property bar : int" syntax on the spot and typed it out just to see
how it looked, then forgot to delete one of the lines before sending...
> void get(out int dest)
> void set(in int i)
Actually that's good too, using 'out' and 'in' instead of 'inout'... That might've been
how I first proposed it. Its been a while.
> 4. Why do you want it to be longer?
Its only a tiny bit longer, actually.
> 5. Why do you want to use void returning functions with out/inout
> parameters instead of returning the type as logical for the REST of C/D?
Consider the problem with opCast, where one can have only a single opCast for a given
class because there is no overload on return type. One method of avoiding this, which has
been proposed, is to use a void return type and a single 'inout'ed parameter. Same basic
idea applies, and admittedly the same basic flaws.
In the end, its a pet desire, and I humbly admit it. But it is one thing I'd really like.
Current properties are, essentially, like a side-effect of a D'ism allowing
single-parameter methods to be invoked as if they were fields. Its cute... but is it wise?
-- Chris Sauls

Chris Sauls wrote:
> Unknown W. Brackets wrote:
>
>> A few questions:
>>
>> 1. What is the benefit this has over the current syntax?
>
> Its more explicit, which I think Properties ought to be.
The current syntax could just as well be made explicit by adding a
'property' attribute, if that's what you mean.
> The current syntax is cute, and does provide the primary requisite
> for clean properties, which is the ability to be seamless between
> fields and methods. Or in other words, to user code a property should
> appear no different from a field.
At the moment, a property does look the same as a field, except that you
can't do ++, *=, etc. with properties. It would be straightforward to
extend the current D property system so that these operators extend to
properties in the natural way. But is your idea going to extend beyond
this?
>> 2. How do you propose to deal with the problem of a single
>> expression/identifier having multiple possible types (which you'll
>> notice D avoids heavily)?
>
> Its a good question. Maybe we could require that there be only one
> gettor, and that its return type match the type of the property. Or
> even that it define that type, so that the property itself actually has
> no type. The type of expressions which use it would then be that of the
> gettor. I'll have to think on it.
I don't see any point in forcing the internal and external types of the
property to be the same. But yes, having only one gettor (getter?)
would be sensible.
<snip>
>> 5. Why do you want to use void returning functions with out/inout
>> parameters instead of returning the type as logical for the REST of C/D?
>
> Consider the problem with opCast, where one can have only a single
> opCast for a given class because there is no overload on return type.
> One method of avoiding this, which has been proposed, is to use a void
> return type and a single 'inout'ed parameter. Same basic idea applies,
> and admittedly the same basic flaws.
<snip>
That only applies if you want a property to be gettable as more than one
type. But to user code, this would be confusing return type overloading
just the same. If we were to allow it in this special case, why not
allow it for normal functions?
If you want to be able to get a property in multiple ways, I was just
thinking about allowing functions with arbitrary names to be defined
within a property block. They would be accessed by
propertyName.functionName. The only problem is that it could get
ambiguous with members of the property's default getter.
Stewart.
--
My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.