I'm thinking that the following operator overload functions will cover the territory. Have I missed anything?

x = foo[y];    =>   x = foo.opIndex(y);

foo[y] = x;    =>   foo.opIndexAss(y, x);

foo[a .. b]     =>   foo.opSlice(a, b);

And yes, I think the other operator overloads should be renamed with an "op" prefix.

> x = foo[y];    =>   x = foo.opIndex(y);
>
> foo[y] = x;    =>   foo.opIndexAss(y, x);
>
> foo[a .. b]     =>   foo.opSlice(a, b);
>
> And yes, I think the other operator overloads should be renamed with an
"op"
> prefix.
>
Why not the whole "operator"?

operatorIndex
operatorAdd
operatorMulass

etc?

Well, I'm not fond of having my ass indexed!

I think a prefix of op is not good enough (i.e. not sufficiently unique).

I would prefer

  OP_slice, or op_slice

As for the two index operators, I think they should be called

  op_index_r and op_index_l (for rvalue and lvalue)

But actually I think this may not be the whole solution. We might want to return a proxy object for both types, as one does in C++. In that case, we'd want

  op_index_l
  op_index_r
  op_index

op_index would only be called where one or other of the l/r variants was not provided.



"Walter" <walter@digitalmars.com> wrote in message news:bjhefn$2qdb$1@digitaldaemon.com...
> I'm thinking that the following operator overload functions will cover the territory. Have I missed anything?
>
> x = foo[y];    =>   x = foo.opIndex(y);
>
> foo[y] = x;    =>   foo.opIndexAss(y, x);
>
> foo[a .. b]     =>   foo.opSlice(a, b);
>
> And yes, I think the other operator overloads should be renamed with an
"op"
> prefix.
>
>

QUS wrote:
> 
> > x = foo[y];    =>   x = foo.opIndex(y);
> >
> > foo[y] = x;    =>   foo.opIndexAss(y, x);
> >
> > foo[a .. b]     =>   foo.opSlice(a, b);
> >
> > And yes, I think the other operator overloads should be renamed with an
> "op"
> > prefix.
> >
> Why not the whole "operator"?
> 
> operatorIndex
> operatorAdd
> operatorMulass

"Add" seems wrong to me, because no element is added in the usual sense.

"Mulass" seems wrong to me, because it is not a "multiple assignment", but
   a single assignment of an array part to an array reference.

In my language built with reusable "words":

  opIndRetElement
  opIndSetElement
  opIndRangeRetSlice

(but I would not expect it to be adopted)

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

"Helmut Leitner" <leitner@hls.via.at> wrote in message news:3F5C45DE.3AC22592@hls.via.at...
>
>
> QUS wrote:
> >
> > > x = foo[y];    =>   x = foo.opIndex(y);
> > >
> > > foo[y] = x;    =>   foo.opIndexAss(y, x);
> > >
> > > foo[a .. b]     =>   foo.opSlice(a, b);
> > >
> > > And yes, I think the other operator overloads should be renamed with
an
> > "op"
> > > prefix.
> > >
> > Why not the whole "operator"?
> >
> > operatorIndex
> > operatorAdd
> > operatorMulass
>
> "Add" seems wrong to me, because no element is added in the usual sense.
>
> "Mulass" seems wrong to me, because it is not a "multiple assignment", but
>    a single assignment of an array part to an array reference.
>
> In my language built with reusable "words":
>
>   opIndRetElement
>   opIndSetElement
>   opIndRangeRetSlice
>
Naaaah! What I meant is just to unfold op to operator. The examples I gave had nothing to do with array overloading :-)

"Walter" <walter@digitalmars.com> ha scritto nel messaggio news:bjhefn$2qdb$1@digitaldaemon.com...
> foo[y] = x;    =>   foo.opIndexAss(y, x);

Maybe opIndexAsLValue, although maybe too verbose, is a better choice. At least it leaves both hands free for typing. ;-)

BTW, I find "op" as a prefix a little too concise; I'd vote for "operator", or "op_" as suggested by Matthew.

Ric

"Walter" <walter@digitalmars.com> wrote in message news:bjhefn$2qdb$1@digitaldaemon.com...
> I'm thinking that the following operator overload functions will cover the territory. Have I missed anything?
>
> x = foo[y];    =>   x = foo.opIndex(y);
>
> foo[y] = x;    =>   foo.opIndexAss(y, x);
>
> foo[a .. b]     =>   foo.opSlice(a, b);
>
> And yes, I think the other operator overloads should be renamed with an
"op"
> prefix.

I'm ok with the short op prefix as you suggest.

I do not see how one could pull off multidimensional arrays without proxy objects.  I think we should be able to declare indexing functions that take more than one argument, and the compiler would give us syntax sugar like so:

template (T : numeric, int cols, int rows)
struct matrix
{
    private T array[rows][cols];
    public T opIndex(int col, int row) { return array[row][col]; }
    public void opIndexSet(T val, int col, int row) { array[row][col] =
val; }
    public instance matrix(T, colrange.end-colrange.begin,
rowrange.end-rowrange.begin).matrix opSlice(range(int) colrange, range(int)
rowrange)
    {
        return
array[rowrange.begin..rowrange.end][colrange.begin..colrange.end];
    }
}

instance matrix(float, 4, 4).matrix mymatrix;
mymatrix[3][2] = 1.0f;   // calls opIndexSet(1.0f,2,3)
float x = mymatrix[3][2];  // calls opIndex(2,3)
instance matrix(float, 2, 2).matrix submatrix = matrix[1..3][0..2];  //
calls opSlice(0..2,1..3)

And one more thing... we need to be able to override the array .length property.  Hopefully you can override a predefined property with a user-defined one.

Sean

Walter wrote:
> I'm thinking that the following operator overload functions will cover the
> territory. Have I missed anything?

Seems to be all there. But you have to know it better. :)
Ah, yes, the multi-dimensional ones would be good, since you provide different names anyway this shouldn't be a problem, right?

> x = foo[y];    =>   x = foo.opIndex(y);
> 
> foo[y] = x;    =>   foo.opIndexAss(y, x);

x = foo[y,z];    =>   x = foo.opIndex(y,z);
foo[y,z] = x;    =>   foo.opIndexAss(y,z,x);

> foo[a .. b]     =>   foo.opSlice(a, b);

foo[a,b .. c,d] =>   foo.opSlice(a,b,c,d);
Could this possibly work at all???

Is it supposed to return a new array or a proxy object at will?

> And yes, I think the other operator overloads should be renamed with an "op"
> prefix.

Seems to be a good idea to me... But what about that _r postfix? You get opDiv_r -- which seems to be inconsistent within itself? How about op_div_r, and so on for operator naming? Or do you prefer opDivR?

Is there any chance to keep naming for array access consistent with properties? In Delphi, an object can contain a number of array acessors which would work like properties. Then you can pick up one of them and set a default attribute for it, then acessing an object as an array would use exactly these acessors... In D this may better simply be the name of the array property.

-eye

"Walter" <walter@digitalmars.com> escreveu na mensagem news:bjhefn$2qdb$1@digitaldaemon.com...
> I'm thinking that the following operator overload functions will cover the territory. Have I missed anything?
>
> x = foo[y];    =>   x = foo.opIndex(y);
>
> foo[y] = x;    =>   foo.opIndexAss(y, x);
>
> foo[a .. b]     =>   foo.opSlice(a, b);
>
> And yes, I think the other operator overloads should be renamed with an
"op"
> prefix.

Why not:


x = foo[y];    =>   x = foo.get(y);

foo[y] = x;    =>   foo.set(y, x);

foo[a .. b]    =>   foo.slice(a, b);


The other operator names are already nice (i.e. "add" instead of "opAdd"). BTW will array operations be overloaded? Today the spec says:


a[] = b[] + 3;    =>  for (int i = 0; i < a.length; i++) { a[i] = b[i] +
3; }


But if I have a collection, will it work? I'm saying that because we'll need to define some array-like data-structures (e.g. matrices, vector spaces) and would be nice to have array operations (like Blitz++ has tensor notation). Perhaps an "indices" operation could be used:


a[] = b[] + 3;

foreach (??? i; a.indices()) {a[i] = b[i] + 3; }


Also it would be nice if I could define more than one index, so a matrix could be written:


x = foo[i, j];        =>   x = foo.get(i, j);

foo[i, j] = x;        =>   foo.set(i, j, x);

foo[0 .. a, 0 .. b]   =>   foo.slice(0 .. a, 0 .. b);


    Best regards,
    Daniel Yokomiso.

"Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us."
 - Bill Watterson


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.514 / Virus Database: 312 - Release Date: 28/8/2003

"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:bjj5bg$2ah0$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> escreveu na mensagem news:bjhefn$2qdb$1@digitaldaemon.com...
> > I'm thinking that the following operator overload functions will cover
the
> > territory. Have I missed anything?
> >
> > x = foo[y];    =>   x = foo.opIndex(y);
> >
> > foo[y] = x;    =>   foo.opIndexAss(y, x);
> >
> > foo[a .. b]     =>   foo.opSlice(a, b);
> >
> > And yes, I think the other operator overloads should be renamed with an
> "op"
> > prefix.
> Why not:
> x = foo[y];    =>   x = foo.get(y);
> foo[y] = x;    =>   foo.set(y, x);
> foo[a .. b]    =>   foo.slice(a, b);
> The other operator names are already nice (i.e. "add" instead of "opAdd").
> BTW will array operations be overloaded? Today the spec says:

Hmm. I kinda was thinking "add" was just a little too generic, that it might need something to say it's a magic function to the compiler. Python sets off the operator overloading with a __ prefix and postfix (which I find unattractive, but it does stand out).

> a[] = b[] + 3;    =>  for (int i = 0; i < a.length; i++) { a[i] = b[i] +
> 3; }
> But if I have a collection, will it work? I'm saying that because we'll
need
> to define some array-like data-structures (e.g. matrices, vector spaces)
and
> would be nice to have array operations (like Blitz++ has tensor notation). Perhaps an "indices" operation could be used:
>
>
> a[] = b[] + 3;
>
> foreach (??? i; a.indices()) {a[i] = b[i] + 3; }

Since [] is a slice operation, I was thinking that this could be handled with the slice operator overload (having it return a different object, with its own operator overloads).

> Also it would be nice if I could define more than one index, so a matrix could be written:
>
>
> x = foo[i, j];        =>   x = foo.get(i, j);
>
> foo[i, j] = x;        =>   foo.set(i, j, x);
>
> foo[0 .. a, 0 .. b]   =>   foo.slice(0 .. a, 0 .. b);

Sean has some ideas along this line:

    x = foo[x][y];    => x = foo.get(x,y);