>>>>> "PJ" == Paul Johnson <[EMAIL PROTECTED]> writes:

  >> how would you propose those callbacks be attached without op codes to do
  >> the callback? :)

  PJ> Well I was specifying requirements rather than proposing
  PJ> solutions, but with this being the internals list I suppose I
  PJ> should have been thinking more about the implementation.  I'm not
  PJ> aware of any firm decisions having been made in this area though.

well, i am sorta pushing for more work to be done on actually
implementing some early core stuff. i proposed work on the event system
even as a learning project to get a portable event system up in perl5.

  >> i think that is best done with inserting special op codes when enabled
  >> by a profiling or debug flag. 

  PJ> Done by what?  Adding opcodes at all conceivable positions could
  PJ> be unnecessarily expensive for most applications, and you're bound
  PJ> to miss something that someone wants.  I would imagine this is
  PJ> best done on a case by case basis, but maybe you were thinking
  PJ> that way too.

you only add these special opcodes when you request it with a pragma or
command line option. most programs don't want profiling, fine grained
debugging, callbacks in special cases, etc. if you ask for them, you
must accept the bloat of extra op codes for those special features.

  >> what dan is trying to do (and i am supporting) is keeping the dispatch
  >> loop as small as possible. it is easier and faster to insert and
  >> dispatch special op codes than to check more flags.

  PJ> I have plenty of sympathy with this view.  I just want to ensure
  PJ> there is sufficient power and flexibility to do all sorts of
  PJ> exciting things.  But everything I've heard so far seems to show
  PJ> that everyone else is after that too.

well, if the op code loop has only 1 flag to check, we just make the
flag settable by multiple events including profile and opcode trace and
debug. in each op loop iteration if the event flag is set a hard coded c
sub is called which then check various event flags to handle them
individually. it would be easy to hook special callbacks into that.  one
important thing would be to make that flag checking sub efficient. it is
not called every op code loop but it could get called often.  maybe
flags are set into groups such that a tree of flags (with their own
handler subs) are tested.

uri

-- 
Uri Guttman  ---------  [EMAIL PROTECTED]  ----------  http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11
Class and Registration info:     http://www.sysarch.com/perl/OOP_class.html

Reply via email to