www.digitalmars.com         C & C++   DMDScript  

D - indexators

reply "Pavel Minayev" <evilone omen.ru> writes:
Indexators support is a feature of C# that I like, and it'd be
great to see it in D as well. Practically, this is an alternate
way to overload operator[] for classes, only you can also
overload assignment operator[]= separately, and with cleaner
syntax. This allows to create pseudo-arrays implemented by
user, and the idea is to hide some code behind element accessing
and/or assignment. Syntax could be like this:

    class Environment
    {
        char[] this[char[] var]()    // gettor
        {
            char* result = getenv(toStringz(var));
            if (result)
                return result[0 .. strlen(result)];
            else
                return "";
        }

        void this[char[] var](char[] value)    // settor
        {
            putenv(toStringz(var ~ "=" ~ value));
        }

        void this[char[] var](int value)    // alternative settor
        {
            this[var] = toString(value);
        }
    }
    Environment env;

And then it'd be used in a simple and intuitive way:

    printf("%.*s\n", env["PATH"]);
    env["PATH"] = 'C:\WINDOWS\COMMAND';
Feb 27 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a5jign$19qv$1 digitaldaemon.com...
 Indexators support is a feature of C# that I like, and it'd be
 great to see it in D as well. Practically, this is an alternate
 way to overload operator[] for classes, only you can also
 overload assignment operator[]= separately, and with cleaner
 syntax. This allows to create pseudo-arrays implemented by
 user, and the idea is to hide some code behind element accessing
 and/or assignment. Syntax could be like this:

     class Environment
     {
         char[] this[char[] var]()    // gettor
         {
             char* result = getenv(toStringz(var));
             if (result)
                 return result[0 .. strlen(result)];
             else
                 return "";
         }

         void this[char[] var](char[] value)    // settor
         {
             putenv(toStringz(var ~ "=" ~ value));
         }

         void this[char[] var](int value)    // alternative settor
         {
             this[var] = toString(value);
         }
     }
     Environment env;

 And then it'd be used in a simple and intuitive way:

     printf("%.*s\n", env["PATH"]);
     env["PATH"] = 'C:\WINDOWS\COMMAND';

I see a new Operator Overloading Flamew... eh discussion coming up :) I support you on this though Pavel, it sounds great! How about using it for multi dimensional arrays though? C++ doesn't support this and you have to overload operator () instead, when to me it seems that the natural syntax would be: Matrix m1 = new Matrix (3,3); m1[0][0] = 12; m1[1][0] = 12; m1[1][1] = 12; etc... -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail
Feb 28 2002
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
Isn't this a nice, convenient way to express the concept of a generalized,
parameterized form of "property"?  (gettor/settor)

If so we should also handle the case where there are no parameters... those
are essentially named converters (converting some other type to the object's
type via a name, or vice-versa by the same name when used as an r-value)

The main difference between what you're proposing and, say, Delphi-style
properties is that yours apply to the whole class, whereas the ones in
Delphi had names which you had to use to access them.

I'd be rather fond of the syntax I think for accessing the properties which
you propose.  But I think it should be generalized so that you can provide a
name if you wish, or have it apply to the class as a whole by using "this"
as the name.

And I think that if you declare one of these which takes no parameters in
the brackets, that brackets should not be required in order to access them?
Maybe?  That gives us almost the same thing as C++'s user-defined conversion
to type& and type const& member function operators.  I don't know if
omitting the [] would cause some kind of ambiguity with copy syntax.  I
guess copy is done with another object of the same type as parameter, and
these use a different type?

Sean

"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:a5lodm$27gl$1 digitaldaemon.com...
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:a5jign$19qv$1 digitaldaemon.com...
 Indexators support is a feature of C# that I like, and it'd be
 great to see it in D as well. Practically, this is an alternate
 way to overload operator[] for classes, only you can also
 overload assignment operator[]= separately, and with cleaner
 syntax. This allows to create pseudo-arrays implemented by
 user, and the idea is to hide some code behind element accessing
 and/or assignment. Syntax could be like this:

     class Environment
     {
         char[] this[char[] var]()    // gettor
         {
             char* result = getenv(toStringz(var));
             if (result)
                 return result[0 .. strlen(result)];
             else
                 return "";
         }

         void this[char[] var](char[] value)    // settor
         {
             putenv(toStringz(var ~ "=" ~ value));
         }

         void this[char[] var](int value)    // alternative settor
         {
             this[var] = toString(value);
         }
     }
     Environment env;

 And then it'd be used in a simple and intuitive way:

     printf("%.*s\n", env["PATH"]);
     env["PATH"] = 'C:\WINDOWS\COMMAND';

I see a new Operator Overloading Flamew... eh discussion coming up :) I support you on this though Pavel, it sounds great! How about using it for multi dimensional arrays though? C++ doesn't support this and you have to overload operator () instead, when to me it seems that the natural syntax would be: Matrix m1 = new Matrix (3,3); m1[0][0] = 12; m1[1][0] = 12; m1[1][1] = 12; etc... -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail

Mar 01 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:a5nmsh$18o$1 digitaldaemon.com...

 Isn't this a nice, convenient way to express the concept of a generalized,
 parameterized form of "property"?  (gettor/settor)

You mean array properties?
 If so we should also handle the case where there are no parameters...

 are essentially named converters (converting some other type to the

 type via a name, or vice-versa by the same name when used as an r-value)

Sorry, I don't get it... an example, please?
 The main difference between what you're proposing and, say, Delphi-style
 properties is that yours apply to the whole class, whereas the ones in
 Delphi had names which you had to use to access them.

In Delphi you could make an arrayed property "default" - which effectively made it the indexator.
 I'd be rather fond of the syntax I think for accessing the properties

 you propose.  But I think it should be generalized so that you can provide

 name if you wish, or have it apply to the class as a whole by using "this"
 as the name.

This would be really great, but it's a lot of work... I think for now indexators will do, since you can always make your own special class with indexator to simulate array property.
 And I think that if you declare one of these which takes no parameters in
 the brackets, that brackets should not be required in order to access

 Maybe?  That gives us almost the same thing as C++'s user-defined

 to type& and type const& member function operators.  I don't know if
 omitting the [] would cause some kind of ambiguity with copy syntax.  I
 guess copy is done with another object of the same type as parameter, and
 these use a different type?

I don't think it's really a good idea. Some different syntax for user-defined cast would be better. Something like: operator cast(int)(Foo foo) { ... } // Foo->int conversion But this would have to wait till operator overloading in general is implemented - which I doubt will happen even in D 1.0... indexators are much simpler to do, since they are practically just overloaded functions with a different syntax.
Mar 01 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a5nubo$4le$1 digitaldaemon.com...
 "Sean L. Palmer" <spalmer iname.com> wrote in message
 news:a5nmsh$18o$1 digitaldaemon.com...

 Isn't this a nice, convenient way to express the concept of a


 parameterized form of "property"?  (gettor/settor)

You mean array properties?
 If so we should also handle the case where there are no parameters...

 are essentially named converters (converting some other type to the

 type via a name, or vice-versa by the same name when used as an r-value)

Sorry, I don't get it... an example, please?
 The main difference between what you're proposing and, say, Delphi-style
 properties is that yours apply to the whole class, whereas the ones in
 Delphi had names which you had to use to access them.

In Delphi you could make an arrayed property "default" - which effectively made it the indexator.
 I'd be rather fond of the syntax I think for accessing the properties

 you propose.  But I think it should be generalized so that you can


 a
 name if you wish, or have it apply to the class as a whole by using


 as the name.

This would be really great, but it's a lot of work... I think for now indexators will do, since you can always make your own special class with indexator to simulate array property.
 And I think that if you declare one of these which takes no parameters


 the brackets, that brackets should not be required in order to access

 Maybe?  That gives us almost the same thing as C++'s user-defined

 to type& and type const& member function operators.  I don't know if
 omitting the [] would cause some kind of ambiguity with copy syntax.  I
 guess copy is done with another object of the same type as parameter,


 these use a different type?

I don't think it's really a good idea. Some different syntax for user-defined cast would be better. Something like: operator cast(int)(Foo foo) { ... } // Foo->int conversion But this would have to wait till operator overloading in general is implemented - which I doubt will happen even in D 1.0... indexators are much simpler to do, since they are practically just overloaded functions with a different syntax.

What about multi-dimensional arrays? Is that possible in Pascal now? Should it be possible in D? -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail
Mar 01 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:a5ob4c$kqf$1 digitaldaemon.com...

 What about multi-dimensional arrays?
 Is that possible in Pascal now? Should
 it be possible in D?

In Pascal, it is possible because of a distinct syntax multidimensional arrays had. In D they look like arrays of arrays so I'm not sure... there could be a way to do it of course: class Foo { int this[int x][int y]() { ... } } Or something like that. But, after all, you can define indexator to return object of type which also has an indexator: class Foo { class Bar { int this[int y]() { ... } } int this[int x]() { return new Bar; } }
Mar 01 2002