Talk:Respond to an unknown method call: Difference between revisions
Talk:Respond to an unknown method call (view source)
Revision as of 21:38, 15 February 2012
, 12 years ago→Go solution: new section
(→PicoLisp solution: wrong function name) |
(→Go solution: new section) |
||
| (4 intermediate revisions by 2 users not shown) | |||
Line 48:
:::::: this would provide the ability to only have specific classes respond to unknown method calls, or have different classes give different responses.--[[User:EMBee|eMBee]] 17:16, 7 November 2011 (UTC)
::::::: Yes, this would work. I avoided a definte class here for generality, but this would make sense for a common superclass. --[[User:Abu|Abu]] 17:58, 7 November 2011 (UTC)
:::::::: well, personally i think that the general case is not really interesting. the ''usual'' (for my understanding of usual) case is to use this for proxy or dispatch classes. that is, a specialized class that represents arbitrary objects in a remote system. so while every other class is normal, this one accepts any message and forwards that message to a different object or remote system. describing the special case for picoLisp would be interesting in contrast to common lisp where such a specialized case is not possible with CLOS without creating a <code>(send)</code> function (i don't know if <code>(call)</code> can be redefined), or adding the checks inside the generic function or <code>(no-applicable-method)</code> because the generic function there is called for any object.
::::::::: From a practical point of view, 'try' is optimal. For example, the PicoLisp GUI framework uses it in several places. It tries to send messages to database objects without knowing about their nature, so that it is up to these objects if and how they display themselves.
::::::::: The point is that when you are about to send a message where you don't know whether the object or its classes implement a method for it or not, you can handle it at the sending side. This keeps the logic local in the sender.
::::::::: The general database classes don't know and don't care about the GUI. No need to define proxy or dispatch classes. Only those concrete classes which should actually respond to these messages need to implement a method for them.
::::::::: In PicoLisp, a method can be defined on-the-fly, for a single object or a class. The code for that definition must not reside in the same source file as the original class, but can be local to the application. --[[User:Abu|Abu]] 08:37, 8 November 2011 (UTC)
== Go solution ==
I'm hoping this satisfies the intent of the task. It does not catch the unknown method at compile time, it does not throw an exception, it does not force the caller to check for the existance of the method nor force the caller to handle the absence of the exception. The caller calls a method on an object, and then it is that method, a method of the receiving object, that handles the absense of the requested method. Defining a CallMethod method seems much like what is done in some other languages when a handler is defined to handle unknown method calls.
The remaining variance which might invalidate the solution is that the method isn't called directly. Go has no syntax for, <pre>object.<expression that evaluates to a method>()</pre> Thus the neccessity of the CallMethod method. —[[User:Sonia|Sonia]] 21:37, 15 February 2012 (UTC)
| |||