On Wednesday, 2 September 2015 at 18:57:11 UTC, Jacob Carlborg
wrote:
I encountered a problem in the implementation of
std.xml.Document.opEquals (yes, I've reported an issue). The
problem is demonstrated with this example:
class Base
{
int a;
override bool opEquals (Object o)
{
On 2015-09-02 22:25, w0rp wrote:
Yeah, I would just call super.opEquals, like so.
I know that's the workaround, but the question is if it's a good
implementation/behavior of opEquals.
--
/Jacob Carlborg
On 9/2/15 2:57 PM, Jacob Carlborg wrote:
In this case the solution/workaround is to explicitly call
super.opEquals, but that will miss some optimizations implemented in
object.opEquals.
Those optimizations have already been exploited by the time you get to
Foo.opEquals, so I wouldn't worry ab
On Thursday, 3 September 2015 at 13:05:49 UTC, Steven
Schveighoffer wrote:
On 9/2/15 2:57 PM, Jacob Carlborg wrote:
In this case the solution/workaround is to explicitly call
super.opEquals, but that will miss some optimizations
implemented in
object.opEquals.
Those optimizations have alrea
On Fri, Sep 04, 2015 at 07:10:25PM +, Jonathan M Davis via Digitalmars-d
wrote:
> On Thursday, 3 September 2015 at 13:05:49 UTC, Steven Schveighoffer wrote:
> >On 9/2/15 2:57 PM, Jacob Carlborg wrote:
> >
> >>In this case the solution/workaround is to explicitly call
> >>super.opEquals, but th
On 09/04/2015 09:21 PM, H. S. Teoh via Digitalmars-d wrote:
Wait, wait, did I miss something? Since when was operator overloading
allowed as free functions?
Since UFCS, but DMD does not implement it.
Or is opEquals a special case?
Yup, quite special: http://dlang.org/operatoroverloading.h
On Friday, 4 September 2015 at 20:39:14 UTC, Timon Gehr wrote:
On 09/04/2015 09:21 PM, H. S. Teoh via Digitalmars-d wrote:
Wait, wait, did I miss something? Since when was operator
overloading
allowed as free functions?
Since UFCS, but DMD does not implement it.
There is nothing in the sp
On Friday, 4 September 2015 at 19:25:35 UTC, H. S. Teoh wrote:
Wait, wait, did I miss something? Since when was operator
overloading allowed as free functions? Or is opEquals a special
case?
Clearly, you haven't read TDPL recently enough. ;)
There is a free function, opEquals, in object.d whi
On 2015-09-05 08:18, Jonathan M Davis wrote:
There is nothing in the spec about supporting operator overloading with
free functions, so I don't know where you get the idea that it's even
intended to be a feature. UFCS applies to functions which use the member
function call syntax, and operators
On 2015-09-05 08:26, Jonathan M Davis wrote:
Clearly, you haven't read TDPL recently enough. ;)
There is a free function, opEquals, in object.d which gets called for
classes, and _it_ is what == gets translated to for classes, and it
calls the member function version of opEquals on classes:
ht
On 09/05/2015 08:18 AM, Jonathan M Davis wrote:
On Friday, 4 September 2015 at 20:39:14 UTC, Timon Gehr wrote:
On 09/04/2015 09:21 PM, H. S. Teoh via Digitalmars-d wrote:
Wait, wait, did I miss something? Since when was operator overloading
allowed as free functions?
Since UFCS, but DMD does
On Saturday, 5 September 2015 at 09:45:36 UTC, Jacob Carlborg
wrote:
On 2015-09-05 08:26, Jonathan M Davis wrote:
Clearly, you haven't read TDPL recently enough. ;)
There is a free function, opEquals, in object.d which gets
called for
classes, and _it_ is what == gets translated to for classe
On Monday, 7 September 2015 at 10:26:00 UTC, Timon Gehr wrote:
On 09/05/2015 08:18 AM, Jonathan M Davis wrote:
On Friday, 4 September 2015 at 20:39:14 UTC, Timon Gehr wrote:
On 09/04/2015 09:21 PM, H. S. Teoh via Digitalmars-d wrote:
Wait, wait, did I miss something? Since when was operator
On Thursday, 3 September 2015 at 06:37:20 UTC, Jacob Carlborg
wrote:
On 2015-09-02 22:25, w0rp wrote:
Yeah, I would just call super.opEquals, like so.
I know that's the workaround, but the question is if it's a
good implementation/behavior of opEquals.
Strictly speaking OO equality ought t
On 09/08/2015 06:49 PM, Jonathan M Davis wrote:
On Monday, 7 September 2015 at 10:26:00 UTC, Timon Gehr wrote:
On 09/05/2015 08:18 AM, Jonathan M Davis wrote:
On Friday, 4 September 2015 at 20:39:14 UTC, Timon Gehr wrote:
On 09/04/2015 09:21 PM, H. S. Teoh via Digitalmars-d wrote:
Wait, wait
On Tuesday, 8 September 2015 at 20:55:35 UTC, Timon Gehr wrote:
On 09/08/2015 06:49 PM, Jonathan M Davis wrote:
Sure, it _could_ be implemented that way, but the only reason I
see to do that is if we're specifically looking to support
defining
overloaded operators outside of the types that they
On 2015-09-08 18:40, Jonathan M Davis wrote:
Well, it might be a bit annoying, but it's simply a matter of adjusting
your code to call opEquals explicitly when trying to call the base
version
Given that fact that I found this problem in std.xml.Document shows
either that this is not so easy t
On 09/09/2015 01:32 AM, Jonathan M Davis wrote:
On Tuesday, 8 September 2015 at 20:55:35 UTC, Timon Gehr wrote:
On 09/08/2015 06:49 PM, Jonathan M Davis wrote:
Sure, it _could_ be implemented that way, but the only reason I
see to do that is if we're specifically looking to support defining
ove
On Saturday, 5 September 2015 at 09:44:13 UTC, Jacob Carlborg
wrote:
On 2015-09-05 08:18, Jonathan M Davis wrote:
There is nothing in the spec about supporting operator
overloading with
free functions, so I don't know where you get the idea that
it's even
intended to be a feature. UFCS applies
On 09/09/2015 09:20 PM, Timon Gehr wrote:
On 09/09/2015 01:32 AM, Jonathan M Davis wrote: (moved from above)
I really don't see any reason why it would even make sense to declare
operators separately from a type.
One reason is that single dispatch can be awkward. A textbook example
would be:
20 matches
Mail list logo
