Re: Inconsistent opcode names
William Coleda [EMAIL PROTECTED] wrote: Is there a reason why we have find_type, but loadlib; eq_str but isnull ? In ancient days the perl5-based assembler tools had troubles with underscores in opcode names, as the operands (for the fullnames) are encoded like: add_p_p_p # add Px, Py, Pz There *was* a restriction. For readability a few more underscores are probably ok: find_ lex, global, type load_ lib, bytecode is_null, same, true, false, lt ... gt# but isa There are likely some more inconsistencies, which should be fixed rather sooner then later. Dan, is that ok with you? leo
Re: Inconsistent opcode names
Leopold Toetsch wrote: There are likely some more inconsistencies, which should be fixed rather sooner then later. One that I noticed: =item Bgetattribute(out PMC, in PMC, in STR) =item Bgetprop(out PMC, in STR, in PMC) - Sam Ruby
Re: Inconsistent opcode names
Sam Ruby [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: There are likely some more inconsistencies, which should be fixed rather sooner then later. One that I noticed: =item Bgetattribute(out PMC, in PMC, in STR) =item Bgetprop(out PMC, in STR, in PMC) Yeah, and get_repr, get_addr. Same with set* - Sam Ruby leo
Re: Inconsistent opcode names
On Sat, Nov 20, 2004 at 08:06:33PM -0500, William Coleda wrote: Is there a reason why we have find_type, but loadlib; eq_str but isnull ? I was just reading something blasting PHP for not being consistent about core naming conventions particularly about this_that vs thisthat. FWIW. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ You're more radiant than a memory of breathtaking ecstasy.
