Newsgroups: perl.perl6.internals
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <d...@sidhe.org>
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-intern...@perl.org
Mime-Version: 1.0
X-Sender: d...@redcap.sidhe.org (Unverified)
Message-ID: <a05111b05b9dcaf450b63@[63.120.19.221]>
In-Reply-To: <3DB4EEF5.70207@toetsch.at>
References: <3D8AE672.7040201@toetsch.at> <3DB4216B.1080409@toetsch.at> <m2d6q3skaz.fsf@helium.physik.uni-kl.de> <3DB4EEF5.70207@toetsch.at>
Date: Wed, 23 Oct 2002 16:04:22 -0400
To: Leopold Toetsch <l...@toetsch.at>,   Juergen Boemmels <boemm...@physik.uni-kl.de>
Subject: Re: [RFC] 2. Proposal for _keyed opcodes
Cc: perl6-intern...@perl.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-SMTPD: qpsmtpd/0.12-dev, http://develooper.com/code/qpsmtpd/
Approved: n...@nntp.perl.org
From: d...@sidhe.org (Dan Sugalski)
Lines: 21

At 8:23 AM +0200 10/22/02, Leopold Toetsch wrote:
>Juergen Boemmels wrote:
>
>>... Also no vtable function has to
>>decide wether its called with 1, 2 or 3 keyed elements.
>
>
>Yes, another advantage, I didn't think of. Currently all _keyed 
>vtable calls have to check, it the key is really there. This could 
>be tossed.

That is an issue, yep, as everything potentially needs to go NULL 
checking. That's the one part of this that I'm not happy with, but 
I'm willing to live with it.
-- 
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk