September 19, 2003
Some long awaited features.

http://www.digitalmars.com/d/changelog.html



September 19, 2003
Walter, you ROCK!

"Walter" <walter@digitalmars.com> wrote in message news:bked8d$2pe5$1@digitaldaemon.com...
> Some long awaited features.
>
> http://www.digitalmars.com/d/changelog.html
>
>
>


September 19, 2003
You're my hero! :)

"Walter" <walter@digitalmars.com> ha scritto nel messaggio news:bked8d$2pe5$1@digitaldaemon.com...
> Some long awaited features.
>
> http://www.digitalmars.com/d/changelog.html
>
>
>


September 19, 2003
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
>
>
>


September 19, 2003
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

September 19, 2003
"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.


September 19, 2003
"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.


September 19, 2003
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


September 19, 2003
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?


September 19, 2003
> 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 :).


« First   ‹ Prev
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home