Nice TWiki > Dev > FeatureProposals > FunctionsReplacedByMultiMethods TWiki webs:
Dev | Doc | Main | TWiki | Sandbox
Dev . { Changes | Index | Search | Go }
Note: this has been implemented, as of Nice 0.9.2 -- DanielBonniot - 18 Oct 2003

Imported email discussion: Could there be a way to also be able to separate the declaration and the definition of a function ? I was thinking about this, since if we could do so, we could really divide declarations and implementations. Thus being able to write files that only contain the 'API' of a package, but not showing the implementation. -- GamsL - 19 Sep 2002

The naive way would make it look like a multi-method. So how would we distinguish them?

One possibility would be to get rid of functions, and only keep multimethods.

Advantages

Simplification. There is only one concept instead of two. People don't need to learn two different syntaxes, and to understand the differences. Better extensibility. A problem with using functions is that you might think when you declare it that you won't need to have several implementations, but then you find out later that you were wrong. If it had been a multi-method from the start, there is no problem here. Exactly this poses a problem ! You remember I had to let the functions work with multimethods (in their body) to guarantee exhaustiveness !

Separation of declarations and implementations. This would be very nice !

Drawbacks

Currently calling a function is more efficient than calling a method, even if there is only one implementation. This could be overcome by an optimization in the compiler. We would loose the ability to forbid new implementations (like final methods in Java). Often this is used to optimize dispatch speed. Since the dispatch code is written at link time in Nice, the compiler can optimize it automatically. Are there justifications for "closing" a method? It is a philosophical question. Some would say that it allows to reason about the exact behaviour of the method. Others would say that "closing" is against the idea of Object Orientation, where everything is open for specialization. Maybe the addition of design by contract can help, since it will allow to impose restrictions on the reimplementations of the method. Will people miss functions? For instance, it seems that the Dylan language used to have only methods, and that they added functions later. So should we go the other way around? See http://www.gwydiondylan.org/old-docs/htdocs/proposal-define-function.txt and http://www.functionalobjects.com/products/doc/core/core_8.htm. I think so too ! What if a programmer uses a final method to optimize dispatch speed ? There might be cases where this feature is solely used for this purpose, and it would be perfectly alright (or even desirable) to add a new implementation ! I guess this should not be forbidden, since DesignByContract? could maybe handle most of the cases where restrictions are necessary, anyway ?!

Proposal

Remove the concept of toplevel function Still accept the current syntax for functions. It will mean: declaration of a multi-method, and default implementation. I like this idea, it fits well I guess !

This has the advantage of keeping backward compatibility with programs using functions. You can still declare a method without the implementation(for instance to separate it in a different section or file). We still keep the distinction between method declaration and method implementation, which I think is very important (while it is blured in Java).

Will it then still be possible to provide the default implementation somewhere else, and just define a method ? Or will it then be necessary to define the default implementation like one currently defines a function ? I shouldn't think so !

Advice

Currently you should keep on using functions when appropriate.

They are more efficient at the moment If I do the change, the same syntax will remain valid, so you won't have anything to change in your source using functions It is less work :-) -- DanielBonniot - 19 Sep 2002

Topic FunctionsReplacedByMultiMethods . { Edit | Attach | Ref-By | Printable | Diffs | r1.2 | > | r1.1 | More }
Revision r1.2 - 18 Oct 2003 - 15:06 GMT - DanielBonniot
Parents: WebHome > FeatureProposals 		Copyright © 1999-2003 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback.