Love your work, but have a gripe and a request.
Gripe: names of special methods as opIndex, opSlice etc are neither
sufficiently unambiguous, or sufficiently eye-catching. Can you explain why
you are not moved by something like __index__, __slice__ or such?
Request: The index operator is documented as taking an int. Can it also
take, say, a char[]? If so, you should put that in the doc. If not, consider
this a request for that?
"Walter" <walter@digitalmars.com> wrote in message
news:bked8d$2pe5$1@digitaldaemon.com...
> Some long awaited features.
>
> http://www.digitalmars.com/d/changelog.html
>
>
>

Walter wrote:
> Some long awaited features.
>
> http://www.digitalmars.com/d/changelog.html
woohoo!
I'm a bit worried about the interface for defining properties. The way
it is, you could do weird things like document.save="filename"; whether
or not it was intended to be used that way.
Is an opIndex overload to handle slice assignment out of the question?
opIndex(start, end, newValue) or somesuch.
Also a tiny note: the opCall and opIndex examples don't use new to
allocate an object. (this has tripped people up in the past, if I recall)
-- andy

"Matthew Wilson" <matthew@stlsoft.org> wrote in message
news:bkf0c3$145b$1@digitaldaemon.com...
> Love your work, but have a gripe and a request.
>
> Gripe: names of special methods as opIndex, opSlice etc are neither
> sufficiently unambiguous, or sufficiently eye-catching.
I put them in boldface in the documentation <g>.
> Can you explain why
> you are not moved by something like __index__, __slice__ or such?
That's what python does. While it does stand out, it kinda doesn't look
right to me, because whenever I see _ _ it looks like some kludgy internal
compiler feature is being accessed.
> Request: The index operator is documented as taking an int. Can it also
> take, say, a char[]? If so, you should put that in the doc. If not,
consider
> this a request for that?
It can take any type - the usual overloading rules apply. The documentation
just gives an example where it uses an int. There can be multiple property
setters, and setters can have a return value.

"Andy Friesen" <andy@ikagames.com> wrote in message
news:bkf0qv$15vh$1@digitaldaemon.com...
> Walter wrote:
> > Some long awaited features.
> >
> > http://www.digitalmars.com/d/changelog.html
>
> woohoo!
>
> I'm a bit worried about the interface for defining properties. The way
> it is, you could do weird things like document.save="filename"; whether
> or not it was intended to be used that way.
Yes, you can do that. Whether you want to or not is a style issue.
> Is an opIndex overload to handle slice assignment out of the question?
> opIndex(start, end, newValue) or somesuch.
I'm a little unsure about that.
> Also a tiny note: the opCall and opIndex examples don't use new to
> allocate an object. (this has tripped people up in the past, if I recall)
That's because they are structs and don't need it (!). I used both struct
and class examples just to show that operator overloading works with each.

Cool beans! We can now make proper matrix and vector and container classes.
the names of the overloading aliases should all be made consistent. If you
use opXxxx for the new ones, they should all be opXxxx.
I just noticed this snippet of docs:
Overloading ++e and --e
Since ++e is defined to be semantically equivalent to (e += 1), the
expression ++e is rewritten as (e += 1), and then checking for operator
overloading is done. The situation is analogous for --e.
I can tell you that ++e is definitely not semantically equivalent to e += 1,
because many things can be incremented but not necessarily by an arbitrary
integer amount (not to mention += negative number).
To really support this you'd need to define
E add(E lop, int rop)
{
if (rop > 0)
{
for (int i = rop; --i >= 0; )
lop++;
}
}
Excellent work!
Sean
"Walter" <walter@digitalmars.com> wrote in message
news:bked8d$2pe5$1@digitaldaemon.com...
> Some long awaited features.
>
> http://www.digitalmars.com/d/changelog.html

Why not __op__op__op__op__index___________ ?
Is that sufficiently eye-catching for you? What do you think adding these
underscores is helping? It's just going to confuse these operators with
everything else that is supposed to stand out visually and someone decides
to add underscores to. It's not like they're keywords.
It's really just requesting that everybody have to type more.
Sean
"Matthew Wilson" <matthew@stlsoft.org> wrote in message
news:bkf0c3$145b$1@digitaldaemon.com...
> Love your work, but have a gripe and a request.
>
> Gripe: names of special methods as opIndex, opSlice etc are neither
> sufficiently unambiguous, or sufficiently eye-catching. Can you explain
why
> you are not moved by something like __index__, __slice__ or such?

> That's what python does. While it does stand out, it kinda doesn't look
> right to me, because whenever I see _ _ it looks like some kludgy internal
> compiler feature is being accessed.
That's exactly what it is: some (not kludgy but...) internal compiler
feature. At least would you consider using the "operator/reverse operator"
keyword as was sugested before? Also name mangling for operators would be
nice so they don't colide with normal methods when linking.
> > Request: The index operator is documented as taking an int. Can it also
> > take, say, a char[]? If so, you should put that in the doc. If not,
> consider
> > this a request for that?
>
> It can take any type - the usual overloading rules apply. The
documentation
> just gives an example where it uses an int. There can be multiple property
> setters, and setters can have a return value.
Nice :).