View mode: basic / threaded / horizontal-split · Log in · Help
September 20, 2003
Re: DMD 0.73 release
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
Re: DMD 0.73 release
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
Re: DMD 0.73 release
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
Re: DMD 0.73 release
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
Re: DMD 0.73 release
"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
Re: DMD 0.73 release
> > 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
operator overloading philosophy
"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
Re: DMD 0.73 release
"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
Re: DMD 0.73 release
"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
Re: operator overloading philosophy
> 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
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home