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)