Dear Michel, I want to thank you for voicing so articulately your opinion, which has encouraged me to voice my own.
Not sure if this is worth your two cents but I'm feeling like, even though using the ultra slickest or heaviest tools will (may? show's what I know:) probably give us a performance hit, vtables are one of the trademark perl compromises; I think that choosing (I'm _going_ to get this wrong) never fewer then three (but never more than 2 + user cleverness) vs always at least four instructions, per Parrot instructions has a strong flavor of "what I probably mean" to it. Am I close to realistic numbers? I know it comes down to being a "performance" thing, anyway. I use perl via (the?) CGI and don't have any good reason to care about this. This is special. Although I can't say I know exactly what the (CPU usage) cost of any particular (perl) instruction is, I've gotten pretty familiar with which things (more or less) slow me down, why this is, and what I, as a believer in the laws of physics, can do about this. IMHO, vtables are a part of perl's persona and ought be preserved, ideally in some kinda of kernal or CPU memory. -Corwin /* Corwin Brust corwin.dreamcafe.com */ ----- Original Message ----- From: "Michel J Lambert" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, March 07, 2002 4:46 PM Subject: Re: Multimethod dispatch for parrot? > > Yes. We will, for actual method and sub dispatch. Not for the other > > vtable methods, though. > > I guess my big 'complaint' was against using vtables for the variety of > operators, due to the inherent asymmetry in them. > > > Mike Lambert > >
