Talk:Respond to an unknown method call: Difference between revisions
Content added Content deleted
(In some languages this task is a bug. What to do?) |
(Omit) |
||
| Line 2: | Line 2: | ||
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? --[[User:Dmitry-kazakov|Dmitry-kazakov]] 18:56, 8 July 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? --[[User:Dmitry-kazakov|Dmitry-kazakov]] 18:56, 8 July 2009 (UTC) |
||
:That means they are statically defined without means for dynamic type resolution, so omit. --[[User:Paddy3118|Paddy3118]] 19:45, 8 July 2009 (UTC) |
|||
Revision as of 19:45, 8 July 2009
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)