Talk:Respond to an unknown method call

Donal, nice task. --glennj 13:59, 4 June 2009 (UTC)

What to do with the languages where this contract violation is always detected at compile time per language design? The task requires to show a way to circumvent the contract that explicitly states that the object x does not support the method f. In a strongly typed language this is impossible to do, which is basically the whole idea of design by contract. Should such languages be mentioned as having no solution? --Dmitry-kazakov 18:56, 8 July 2009 (UTC)

That means they are statically defined without means for dynamic type resolution, so omit. --Paddy3118 19:45, 8 July 2009 (UTC)

Java was omitted for that reason. That seems like a good solution. --Mwn3d 19:45, 8 July 2009 (UTC)

Note that Java has the opposite operation — the ability to dispatch to an existing method that you don't know at compile time — through its reflection classes, and it's actually very useful for me as I tend to write dynamic code in any language. I need to check whether there's a task to allow people to write about their language's ability to introspect its objects/classes to discover what methods are available and dispatch to them, but that's not this task; this task is about those languages which allow objects to accept any message if they wish (some like this, some don't; it's a philosophical thing). —Donal Fellows 09:01, 9 July 2009 (UTC)

I see that some languages are putting in how they do errors when you try to do an unknown method. This is wrong! The object must have a chance to respond to a method call (or message) which it doesn't know the name/topic of ahead of time. Throwing an error at compile time is the total antithesis of this. I'm going to go through and remove all the contributions by people who have obviously "not got it". –Donal Fellows 15:05, 25 February 2010 (UTC)

Don't remove, but mark them incorrect, and include your reasoning. If you remove them, there's not much trace of why it was removed, and some editor who comes along and drops in a new example might make the same mistake. If someone fluent in the language then comes along and marks it with the Omit template, then that's that. --Michael Mol 16:14, 25 February 2010 (UTC)

I've marked them both with the omit template on the basis that they clearly stated "we can't do this"; that's quite enough evidence for me to just apply the correction. Don't mind them being omitted. Do mind a grand kerfuffle while they decide that they've made an error and change to what they're supposed to do. And yes, I'm a bit irascible today; comes of dealing with too many telecons and not enough progress. –Donal Fellows 16:32, 25 February 2010 (UTC)

PicoLisp solution

Sorry, I don't get it. The examples *do* demonstrate how to respond to an unknown message. If 'try' does not succeed, you can take any other measure you like (as here sending some other (known) message to the object). You might also call some other function on that object if you like, but that's not the point. Abu (moved from main page)

the current solution does not respond to the unknown method call, it merely does a different call if the unknown calls fail.

a correct solution would let the call (try 'message1> Obj) be successful. and actually it shouldn't even need to use (try), but it should be possible to directly call (message1> Obj) without error.--eMBee 08:37, 7 November 2011 (UTC)

No, it is not the case that the unknown call "fails" in the examples. Instead, his is a controlled behavior, and exactly the purpose of 'try'.

There are three ways to send a message to an object in PicoLisp: (message1> Obj), (send 'message1> Obj) and (try 'message1> Obj). The standard way, (message1> Obj), is just a convenient abbreviation of (send 'message1> Obj). They all three do a dynamic search for a definition of 'message1>' in Obj and its (super)classes. If a method definition is found, it is executed in the context (i.e. 'This') of Obj. If no such method is found, the case must be handled explicitly (what else?). And that's what 'try' is for, because the direct call and the one with 'send' throw an error.

So 'try' is the "primitive" form of 'send', which allows you to roll your own special method invocation, like calling (try 'unknown> Obj), and handling it yourself. Then calling some other function or method is the only way for the object to "respond (sensibly/usefully)". Not that an object can never "respond" all by itself, there must always be some function call involved (explictly or implicitly). --Abu 00:55, 7 Nov 2011 (UTC)

BTW, note that under the premise that "the object responds to the method call" the Common Lisp solution is also wrong. The "object" by itself doesn't do anything. The CL solution defines a _default_handler_, which is effectively the same as taking a _default_action_ after calling 'try'. (Not to mention that the latter method is more flexible, the action can be also dynamic depending on the situation, while the default handler is static and immuatble at that moment) --Abu 11:52, 2 July 2011 (UTC)