Is there the way to make properties like Delphi, so that writing and reading this property is processed with different function and procedure.

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

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

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

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

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

> 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"];

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.

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"];
>
>