September 20, 2003 Re: DMD 0.73 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Boucher | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew Wilson | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew Wilson | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean L. Palmer | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew Wilson | "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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean L. Palmer | > > 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean L. Palmer | "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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew Wilson | "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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Wynn | "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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | > 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 |
Copyright © 1999-2021 by the D Language Foundation