On Sat, Jul 26, 2008 at 10:38 PM, Bob Rogers <[EMAIL PROTECTED]> wrote: > From: Mark Glines <[EMAIL PROTECTED]> > Date: Tue, 22 Jul 2008 21:58:10 -0700 > > . . . > > Integer is a good example of the problem, actually. > > The internal storage format doesn't change, but the methods you can call > on it definitely will. HLLs wrap the Integer class with their own > subclasses, so that they have methods they can call on integers, which > are expected by the HLL. > > 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. > > -- Bob >
Is this the recommended approach then, instead of creating subclasses? 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
