Pike v7.7 release 13 running Hilfe v3.5 (Incremental Pike Frontend)
ADT.Relation.Binary();
(1) Result: ADT.Relation.Binary(0 0)
object x=_;
Compiler Error: 1:Error comparing constants. Compiler Exception: C stack overflow. ...
Binary.pike:
int(0..1) `==(mixed rel) { if (predef::`==(rel, this)) return 1; // This is never reached.
predef::`== will just call `== in the object, won't it? So what you have written is an infinite recursion.
predef::`==() is (by definition) the same as the plain == operator. What did you expect it to be?
My guess: testing whether two objects are the same object instance, regardless of the presence of an `== operator in the other object. Perhaps misguided, but it is an operation that seems useful to have (under some name).
Thanks. I (and perhaps the person behind the shown code) don't use it often enough to remember its name.
how do i access that in a class with a parent that implements `==()? wouldn't ::`==() then get the parents definition instead of the one talked about here?
it seems odd to use an unspecified :: to access this (uhm, what is it anyways, global? top level?) function.
greetings, martin.
well, that is the question, how do i do == on this_object if the parent has a `==()?
greetings, martin.
i guess, i need to create an example, but first i am trying to recreate the original problem with predef failing, so hold that question for a moment and help me to recreate the original problem that martin had observed:
$ cat main.pike void main() { object a=((program)"equal.pike")(); object b=a; if(a==b) write("equal"); }
$ cat equal.pike int(0..1) `==(mixed rel) { if (predef::`==(rel, this)) return 1; // This is never reached. }
this creates the loop, as previously noted.
now, the suggested solution was to do remove the "predef": $ cat equal.pike int(0..1) `==(mixed rel) { if (::`==(rel, this)) return 1; // This is never reached. }
$ pike main.pike equal.pike:3:Undefined identifier "::`==". Compilation failed. /usr/local/pike/7.6.7/lib/master.pike:346: master()->compile_string("int(0..1) `==(mixed rel)\n{ \n if (::`==(rel, t his))\n return 1; // This is never reached.\n}\n","/local/home/mbaehr/s rc/pike/inherit/equal/equal.pike",0,equal.pike,0) /usr/local/pike/7.6.7/lib/master.pike:813: master()->low_findprog("/local/home/mbaehr/src/pike/inherit/equal/equal"," .pike",0,0) /usr/local/pike/7.6.7/lib/master.pike:907: master()->findprog("/local/home/mbaehr/src/pike/inherit/equal/equal",".pik e",0,0) /usr/local/pike/7.6.7/lib/master.pike:955: master()->low_cast_to_program("equal","/local/home/mbaehr/src/pike/inherit /equal/main.pike",0,0) /usr/local/pike/7.6.7/lib/master.pike:977: master()->cast_to_program("equal.pike","/local/home/mbaehr/src/pike/inheri t/equal/main.pike",0) main.pike:3: /local/home/mbaehr/src/pike/inherit/equal/main()->main()
what am i missing here?
ok that does make sense, but then i don't understand why in nilssons example ::`==() should have been used.
at least i did not get from the context that Binary.pike would necessarily have a parent that defines `==()
greetings, martin.
If the parent has `== you will probably want to call it.
Normally you just compare all the variables,
int `==(object x) { return x->a==a && x->b==b; }
but I agree that sometimes you want to check if it's actually the same object.
we were talking about predef::`==() vs ::`==()
and now you bring in lfun::`==()
how does that fit in?
btw: i still miss an explanation for why my sample code crashes.
greetings, martin.
we were talking about predef::`==() vs ::`==()
and now you bring in lfun::`==()
predef::`==() is the == operator. lfun::`==() is the object comparison callback called by predef::`==(). ::`==() is the inherited lfun::`==() (if any).
btw: i still miss an explanation for why my sample code crashes.
What code?
On Fri, Jan 14, 2005 at 03:45:02PM +0100, Henrik Grubbström (Lysator) @ Pike (-) developers forum wrote:
btw: i still miss an explanation for why my sample code crashes.
What code?
i sent it before in this thread. Message-ID: 20050112210441.GA4072@email.archlab.tuwien.ac.at
is the importer missing messages?
greetings, martin.
That's a problem with all the "magic" operators (::`->, ::_indices, etc). If we can come up with a better syntax it shouldn't be very hard to keep them accessible. I don't see any point with that a parent class can keep them inaccessible from the inheriting class, if there ever was such an intention.
A point in case is also that those functions aren't quite the same thing as the operators whose names they use. It shows for instance in the intentionally undocumented indexing type argument to ::`->, ::`->=, ::_indices and ::_values. With that argument, it's possible to access static class members and members of inheriting classes. This indexing type argument isn't a good solution (which is why it has remained undocumented); I think there ought to be a separate function for each indexing type instead. I.e. ::`-> should be broken up into at least four separate indexing functions, etc.
pike-devel@lists.lysator.liu.se