www.digitalmars.com         C & C++   DMDScript  

D - indexators

reply "Pavel Minayev" <evilone omen.ru> writes:

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


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


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


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)


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


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.


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


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?


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




generalized,

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


 You mean array properties?


 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)


 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


 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.


 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


 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?


 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