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';

"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

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

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

"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

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