Chip Salzenberg wrote:
On Fri, Sep 09, 2005 at 01:48:20PM +0200, Leopold Toetsch wrote:
[ opt_count --> :opt_flag ]
If there is an alternating sequence of (:optional, :opt_count)+, the
:opt_count works exactly like :opt_flag, i.e. you get 0 or 1 depending
on the presence of the preceeding optional argument.
OTOH the current :opt_count is also usable to just count a bunch of
preceeding optionals. Therefore this proposed change would just reduce
the functionality of the current implementation.
But seriously: I've been asking you to remove the counting feature
for, what, months now? And for a consistent reason: Future
development of the parameter passing interface will likely make it
inconvenient (read 'inefficient') to implement.
Sorry, I still don't see the "consistent" reason. The future dev might
include named arguments, which, for a general :opt_count, could imply
another scan through the arguments.
But reasoning on possible performance impacts within a feature that is
more heavy-weight anyway (hash lookups!) is not really a convincing
argument.
Having just an :opt_flag OTOH implies more arguments to be passed and
implies more used registers at the callee's code for more then 1
:optional. E.g.: PGE::Expr::new() has 3 :optional and 1 :opt_count. With
:opt_flag this would take 6 arguments to pass and 2 more used registers.
This will cause some slowdown.
... And the current user
base (pretty much Patrick and the tcl guys) have said they don't mind
switching to a boolean.
Tcl is using :slurpy only currently, there are just 14 uses of
:opt_count in the whole parrot tree. It's not a big deal to change it,
*if* needed :-)
* subroutine attribute spelling: "method" -> ":method"
.sub "foo" :multi(_,int) :method
ACK. What about @MAIN, @IMMEDIATE, ...?
Same deal: the colon form will be standard, but the @ form should be
accepted until users have switched (or a few months, whichever comes
first). It's a totally minor point, I know, but I have a weakness for
the perl 5 modifier syntax.
Ok. I'll put in colon aliases for all, the comma separator would be
optional for now.
* src/inter_run.c : runops_args() - argument limit
OK, but please add a FIXME comment.
Done.
There's no rush of course on the deletions, but I didn't think opcode
renumbering could break pasm code. I'd like to understand the interaction.
Not PASM - PBC.
[ ref_count ]
Why not let GC handle the contexts too? Objects don't have to be
"first-class" or user-visible for GC to handle them, right?
Only PObjs (PMC, STRING) can be subject of GC. A context is a secondary
citizen, depending on the live-flag of continuations.
leo
