View mode: basic / threaded / horizontal-split · Log in · Help
June 12, 2005
Way to make properties
Is there the way to make properties like Delphi, so that writing and reading
this property is processed with different function and procedure.
June 12, 2005
Re: Way to make properties
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".
June 12, 2005
Cool =)
June 12, 2005
Re: Way to make properties
Vathix wrote:
> 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".

I still think we'd be better off with C# style properties (I don't know 
how Delphi's props work.. someone show me an example?).  As I do 
everytime this comes up, I'll show my suggested syntax once again. 
Apologies to those of you who have seen this a thousand times.  But I'm 
adamant.  :)

# class Foo {
#   public property bar : int {
#   public int property bar {
#     void get(inout int    dest){ dest = _value;                      }
#     void get(inout char[] dest){ dest = std.string.toString(_value); }
#
#     void set(inout int    src){ _value = src;        }
#     void set(inout char[] src){ _value = toInt(src); }
#   }
# }
June 12, 2005
Re: Way to make properties
A few questions:

1. What is the benefit this has over the current syntax?
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)?
3. Why do you have two (different) lines declaring the property?

In essence, I see you want to change this:

class Foo
{
   int _value;

   int bar()
   {
      return this._value;
   }
   void bar(int i)
   {
      this._value = i;
   }
}

To:

class Foo
{
   int _value;

   public int property bar
   {
      void get(out int dest)
      {
         dest = this._value;
      }
      void set(in int i)
      {
         this._value = i;
      }
   }
}

Which brings the following questions:

4. Why do you want it to be longer?
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?

-[Unknown]


> I still think we'd be better off with C# style properties (I don't know 
> how Delphi's props work.. someone show me an example?).  As I do 
> everytime this comes up, I'll show my suggested syntax once again. 
> Apologies to those of you who have seen this a thousand times.  But I'm 
> adamant.  :)
> 
> # class Foo {
> #   public property bar : int {
> #   public int property bar {
> #     void get(inout int    dest){ dest = _value;                      }
> #     void get(inout char[] dest){ dest = std.string.toString(_value); }
> #
> #     void set(inout int    src){ _value = src;        }
> #     void set(inout char[] src){ _value = toInt(src); }
> #   }
> # }
June 13, 2005
Re: Way to make properties
Agreed

"Chris Sauls" <ibisbasenji@gmail.com> wrote in message news:d8i1s9$10f$1@digitaldaemon.com...
> Vathix wrote:
>> 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".
>
> I still think we'd be better off with C# style properties (I don't know how Delphi's props work.. someone show me an 
> example?).  As I do everytime this comes up, I'll show my suggested syntax once again. Apologies to those of you who 
> have seen this a thousand times.  But I'm adamant.  :)
>
> # class Foo {
> #   public property bar : int {
> #   public int property bar {
> #     void get(inout int    dest){ dest = _value;                      }
> #     void get(inout char[] dest){ dest = std.string.toString(_value); }
> #
> #     void set(inout int    src){ _value = src;        }
> #     void set(inout char[] src){ _value = toInt(src); }
> #   }
> # }
June 13, 2005
Re: Way to make 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
June 13, 2005
Re: Way to make properties
> I still think we'd be better off with C# style properties (I don't know 
> how Delphi's props work.. someone show me an example?).  As I do everytime 
> this comes up, I'll show my suggested syntax once again. Apologies to 
> those of you who have seen this a thousand times.  But I'm adamant.  :)
>
> # class Foo {
> #   public property bar : int {
> #   public int property bar {
> #     void get(inout int    dest){ dest = _value;                      }
> #     void get(inout char[] dest){ dest = std.string.toString(_value); }
> #
> #     void set(inout int    src){ _value = src;        }
> #     void set(inout char[] src){ _value = toInt(src); }
> #   }
> # }

I agree, but have a preference for the flexible syntax implemented in 
C++/CLI 
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1600.html).

   class Address {
       property int houseNumber {
           int get() { return houseNumber_; }
           void set(int value) { houseNumber_ = value; }
       }
       property char[] town {
           final char[] get() { return town_; }
       }
       private char[] town_;
       private int houseNumber_;
   }

You can also have named indexers, which would be nice to have (D only offers 
opIndex). These can be used to eliminate the need to define separate 
containers for array-like access:

   class Library {
       property Author authors[char[]] {
           Author get(char[] name) { ... }
       }
   }

instead of:

   class Library {
       class AuthorCollection {
           Author opIndex(char[] name) { ... }
           ...
       }
       AuthorCollection authors() { return authorCollection_; }
       private AuthorCollection authorCollection_;
   }

   Author author = myLibrary.authors["Murdoch, Iris"];
June 13, 2005
Re: Way to make properties
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.
June 13, 2005
Re: Way to make properties
I don't understand why you all seem intent on making the language so
verbose. Wouldn't the following be a lot clearer and less error-prone:

class A {
 property int houseNumber;
}

With the compiler generating the get and set methods?

For a read-only fields:
class A {
 property readonly int houseNumber;
}

The underlying implementation is trivial and (almost)always identical from
one instance to the next. Let's allow one to define a special setter or
getter if need be, but don't force one to write it...

An alternative (even less verbose) syntax:

class A {
 property {
    int houseNumber;
    readonly char[] street;
  }
}

One that I would even like best (but hey, that's just me!)
class A {
 rw int houseNumber;   // read-write property
 ro street street; // read-only property
}




"John C" <johnch_atms@hotmail.com> wrote in message
news:d8ji1p$19e2$1@digitaldaemon.com...
> > I still think we'd be better off with C# style properties (I don't know
> > how Delphi's props work.. someone show me an example?).  As I do
everytime
> > this comes up, I'll show my suggested syntax once again. Apologies to
> > those of you who have seen this a thousand times.  But I'm adamant.  :)
> >
> > # class Foo {
> > #   public property bar : int {
> > #   public int property bar {
> > #     void get(inout int    dest){ dest = _value;                      }
> > #     void get(inout char[] dest){ dest = std.string.toString(_value); }
> > #
> > #     void set(inout int    src){ _value = src;        }
> > #     void set(inout char[] src){ _value = toInt(src); }
> > #   }
> > # }
>
> I agree, but have a preference for the flexible syntax implemented in
> C++/CLI
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1600.html).
>
>     class Address {
>         property int houseNumber {
>             int get() { return houseNumber_; }
>             void set(int value) { houseNumber_ = value; }
>         }
>         property char[] town {
>             final char[] get() { return town_; }
>         }
>         private char[] town_;
>         private int houseNumber_;
>     }
>
> You can also have named indexers, which would be nice to have (D only
offers
> opIndex). These can be used to eliminate the need to define separate
> containers for array-like access:
>
>     class Library {
>         property Author authors[char[]] {
>             Author get(char[] name) { ... }
>         }
>     }
>
> instead of:
>
>     class Library {
>         class AuthorCollection {
>             Author opIndex(char[] name) { ... }
>             ...
>         }
>         AuthorCollection authors() { return authorCollection_; }
>         private AuthorCollection authorCollection_;
>     }
>
>     Author author = myLibrary.authors["Murdoch, Iris"];
>
>
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home