From: "Will Coleda" <[EMAIL PROTECTED]>
Date: Thu, 31 Jul 2008 14:47:36 -0400
On Sat, Jul 26, 2008 at 10:38 PM, Bob Rogers
> Since HLLs can define their own multimethods on the existing Integer
> class without subclassing, and without fear of conflict, that is not
> sufficient reason for it.
Is this the recommended approach then, instead of creating subclasses?
It's certainly what I would recommend. ;-}
What if two HLL's wanted to add multimethods of the same name? (I'm
not sure how they would not conflict, since the multimethods would
have to live in the toplevel 'parrot' namespace to affect the base
Integer PMC.)
--
Will "Coke" Coleda
Multisubs live in namespaces; multimethods do not (at least not
uniquely), so you have to be careful to say what you mean by "name."
The "short name" is the name of the multisub, which you would indeed
need to use in order to add multimethods to it. However, when I said,
"HLLs can define their own multimethods," I really meant "... their own
multisubs" (sorry), and was assuming that they would put them in one of
their own namespaces, i.e. they would not need to be public. So nobody
else could call them (without realizing that they were intruding, of
course).
When you add multimethods, though, you are defining them (implicitly)
by their "long name"; redefining the same long name would indeed cause a
conflict. Effectively, you would be redefining the behavior of an
existing multisub for the same combination of existing classes. I doubt
this arises much in practice. The normal case would be to add a
multimethod that specializes on one or more new classes introduced by
the foreign HLL or module. CL apps have been specializing each others'
multisubs this way for decades. (Concrete counterexamples welcome, of
course.)
In short, if you want some different behavior that involves integers
(modular arithmetic, say?), you need to define a new multisub, and there
can be no conflict with other languages. If you want the behavior
defined for some existing multisub to be different for a new class that
what it would get by inheritance, then you must define methods
specialized to that class, and there is still no conflict. In both
cases, if you want language-specific classes to behave properly when
passed into other languages (including your own), it behooves you to
pick the most general classes that still make sense when defining the
other types on which the new method specializes.
Of course, specific HLL programs may fail if they happen to examine
an exotic complex number, choking on a Ratio as a real or imaginary
component. But such a thing Might Just Work, as long as the program is
using sufficiently generic arithmetic. Therefore, IMHO, conversion from
"exotic" types to less specialized ones ought to be provided as an
optional facility by language implementors, under the control of the
language users. What Parrot needs to do is provide hooks for the
language implementors so that the language can convert from types it
does not yet understand. (So I suppose I do have to agree that some
mapping is unavoidable.)
FWIW, I have started on a draft proposal for language interop, which
I hope to have in a publishable state by the weekend . . .
-- Bob
