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. Please fix the code and remove this message.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)