On Wed, Jun 25, 2008 at 12:19:13PM -0500, Patrick R. Michaud wrote: > > What's the general policy for that? Just like this, and Complex-only > > multis in classes/Complex.pir? > > Or everything into Complex.pir? > > Or everything but the ops in Complex.pir, and ops into builtins/op.pir? > > In this specific instance I'd prefer that the Complex operator > definitions go into src/classes/Complex.pir .
Another possibility would be to have the operators always use the PMC forms of the opcodes (instead of the int/string/num versions), and make vtable overrides in Object/Any/(whatever) so that the opcodes still dtrt when passed a PMC that doesn't already map to the operation. This is one of those areas where Parrot gets a little confusing -- we can either solve the problem via multisub dispatch at the HLL level, or we can solve it via vtable dispatch at the Parrot level (and whichever way we do it needs to work in both contexts). I haven't decided whether we should be giving primacy to multisub dispatch, vtable dispatch, or a convoluted mixture of both. Pm
