September 20, 2003
That is an interesting idea!  It's a very common operation.

Sean

"John Boucher" <John_member@pathlink.com> wrote in message news:bkfh2j$2dd4$1@digitaldaemon.com...
> This again brings to mind what I was thinking about for strings...
> I was considering the benefit of overloading the ++ and -- operators for
> strings... They could be toUpper() and toLower() operators!!



September 20, 2003
If you want to have it be easier to parse, require an underscore between them.  Or whatever the preferred language multi-word-naming style is. InitialCaps?

operator_cmp()
operator_add()

Sean

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkgh89$2d4f$1@digitaldaemon.com...
> I'm equally happy with __add__ and operator add(). Just not opAdd
>
> In fact I think I like operator add() more.
>
> However, it begs the question why we just don't have operator +() ?
>
> "Walter" <walter@digitalmars.com> wrote in message news:bkgdgr$1vnq$1@digitaldaemon.com...
> >
> > "Julio César Carrascal Urquijo" <adnoctum@phreaker.net> wrote in message news:bkgc6t$1rdg$1@digitaldaemon.com...
> > > They could be the short names that we have right now:
> > >
> > > operator cmp()
> > > operaror add()
> > > operator addass()
> > > ...
> > >
> > > The thing is that they should not collide with regular user-defined
> > methods
> > > (Hence the name mangling). The new "operator" keyword should stand out suficiently and probably will be easier for syntax highlighting
> algorithms
> > > than using regular methods with special names.
> >
> > Hmm. I do like that better than __xxx__ !


September 20, 2003
Hear!

In many cases it is not possible to determine which of two classes should have the operator.

What if two different classes both overload operators on the other class? Is that a conflict?

class A { operator_cmp(B b) { return -b.cmp(this); } }
class B { operator_cmp(A a) { return -a.cmp(this); } }

It would be best if you just put it in the global namespace

operator A a cmp B b noncommutative
{
    return a.member < b.member ? -1 : a.member == b.member ? 0 : 1;
}

Sean

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkghmm$2eu1$1@digitaldaemon.com...
> Also, all this merry nomenclatural banter masks the deeper issue of
concern
> that operators are member functions. :(


September 20, 2003
Koenig lookup next stop. He he

I understand why language writers (C# & D, at least) have favoured having them defined as class members, but it's simply wrong.

Having said that, I can probably live with them as such, if only they were static.

Don't get me wrong: you're completely right about it. I'm just being a pragmatist as usual.


"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bkgl1k$2rbe$1@digitaldaemon.com...
> Hear!
>
> In many cases it is not possible to determine which of two classes should have the operator.
>
> What if two different classes both overload operators on the other class? Is that a conflict?
>
> class A { operator_cmp(B b) { return -b.cmp(this); } }
> class B { operator_cmp(A a) { return -a.cmp(this); } }
>
> It would be best if you just put it in the global namespace
>
> operator A a cmp B b noncommutative
> {
>     return a.member < b.member ? -1 : a.member == b.member ? 0 : 1;
> }
>
> Sean
>
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkghmm$2eu1$1@digitaldaemon.com...
> > Also, all this merry nomenclatural banter masks the deeper issue of
> concern
> > that operators are member functions. :(
>
>


September 20, 2003
"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkgldj$2slf$1@digitaldaemon.com...
> Koenig lookup next stop. He he

You're funny!!  ;)

> I understand why language writers (C# & D, at least) have favoured having them defined as class members, but it's simply wrong.

yes

> Having said that, I can probably live with them as such, if only they were static.

I don't understand.

> Don't get me wrong: you're completely right about it. I'm just being a pragmatist as usual.

Don't worry about it.

Sean

> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bkgl1k$2rbe$1@digitaldaemon.com...
> > Hear!
> >
> > In many cases it is not possible to determine which of two classes
should
> > have the operator.
> >
> > What if two different classes both overload operators on the other
class?
> > Is that a conflict?
> >
> > class A { operator_cmp(B b) { return -b.cmp(this); } }
> > class B { operator_cmp(A a) { return -a.cmp(this); } }
> >
> > It would be best if you just put it in the global namespace
> >
> > operator A a cmp B b noncommutative
> > {
> >     return a.member < b.member ? -1 : a.member == b.member ? 0 : 1;
> > }
> >
> > Sean
> >
> > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkghmm$2eu1$1@digitaldaemon.com...
> > > Also, all this merry nomenclatural banter masks the deeper issue of
> > concern
> > > that operators are member functions. :(
> >
> >
>
>


September 20, 2003
> > Having said that, I can probably live with them as such, if only they
were
> > static.
>
> I don't understand.

Even though your assertion that they should be in the global namespace is correct I, as a pragmatic fellow, will be content (at least to the point of ceasing my whingeing) if they are implement as *static* member functions. I can't live with the status quo, of them as non-static member functions, and I don't plan to stop campaigning against them (see this month's CUJ!)






September 20, 2003
"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bkgj6v$2k11$1@digitaldaemon.com...
> So can you ++ floats then?  ;)

Yes.

> What if I want my class to be able to add, but not ++?  For instance if there is no well defined "next" to go to, but you can "add" some arbitrary amount.  For instance, maybe a set.  Yeah this example is probably an
abuse
> of operator overloading (you'd probably overload ~=).  You can add items
to
> a set but can't increment a set.

This goes back to what I think operator overloading should be for. It should be for adding (!) arithmetic to user defined data types. I think it is not appropriate to overload << to be anything but a shift operation, i.e. using it as 'insert' is just not right. I don't agree with the notion that, for example, ++ could be overloaded to mean 'get the next item in the list'.

This is reflected in the design of the operator overloading in D, such as + is commutative and / is not. It is not meant to support the notion that ++ is fundamentally different from +=. I think operator overloading should be used much more conservatively than how it is popularly used in C++. People shouldn't have to look for an operator overload of += to find out that what it is doing has nothing at all to do with adding.


September 20, 2003
"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkgin8$2hs0$1@digitaldaemon.com...
> This is not a great emergency, since the above workaround is eminently reasonable. However, it'd be good if it could be fixed in 0.74

No problem. I expect problems like that to crop up on the first try at a great new feature!


September 20, 2003
"Mike Wynn" <mike@l8night.co.uk> wrote in message news:bkgk91$2nvf$1@digitaldaemon.com...
> Walter wrote:
> > Some long awaited features.
> >
> > http://www.digitalmars.com/d/changelog.html
> >
>
> is it just me or is int opSlice() pointless ?
>   I've written a copy on extend slice class but howcan I write the
> overloaded operator to allow
> a[]=b[]; to work as it does for arrays
> there is no operator =/assign

Looks like I need to add something for that here.


September 20, 2003
> This goes back to what I think operator overloading should be for. It
should
> be for adding (!) arithmetic to user defined data types. I think it is not appropriate to overload << to be anything but a shift operation, i.e.
using
> it as 'insert' is just not right. I don't agree with the notion that, for example, ++ could be overloaded to mean 'get the next item in the list'.
>
> This is reflected in the design of the operator overloading in D, such as
+
> is commutative and / is not. It is not meant to support the notion that ++ is fundamentally different from +=. I think operator overloading should be used much more conservatively than how it is popularly used in C++. People shouldn't have to look for an operator overload of += to find out that
what
> it is doing has nothing at all to do with adding.

Quite right. Transgressors should be weeded out and forced to 3yrs hard VB.NET before they're allowed back on parole