[pypy-dev] opcodes bundled in a class?

[holger krekel]

hello pypy,

with the builtinrefactor branch i am at the point where i want
to eliminate the 'appfile' concept alltogether in favour of 
intermingling app-level and interp-level code directly.  And before 
i start to fix the stdobjspace (which still isn't working) i'd like 
to get rid of 'opcode_app.py' so that the interpreter is 'appfile'-free.  

It's easier to do this when the implementation of the opcodes 
(interp- or applevel) lives in methods of a to-be-created "Opcode" 
class.  That's because a class can naturally be instantiated (with
a space argument) and all app-level functions can be processed
so they end up beeing an 'InterpretedFunction' instance which you 
can seemlessly/natively invoke at interp-level. e.g.

    def BUILD_CLASS(self, f):
        w_meths = f.valuestack.pop()
        w_bases = f.valuestack.pop()
        w_name  = f.valuestack.pop()
        w_newclass = self.build_class(w_name, w_bases, w_meths, f.w_globals)
        f.valuestack.push(w_newclass)

    # not callable as is, takes no self-argument
    def app_build_class(name, bases, meths, globals):
        ...
        return metaclass(name, bases, namespace)

I also think that our internal 'InterpretedFunction' or 'Code' object 
should be responsible for delivering an 'opcode' class specific to 
its code and space. This would also allow using a different opcode-set 
(and implementation) for certain functions. Eventually it might be 
possible to implement or invent bytecodes at app-level.  The key 
task here is to have a compiler package that produces code objects 
with a specific 'Opcode' class indication. 

However, is anybody against putting the opcodes/helpers in a class? 

Note that the 'visilibity' feature that Armin mentioned ealier
is currently not done.  But there already is a concept called
'AppVisibleModule' also living in the gateway module. It wraps
itself into an app-visible module.  E.g. the 'builtin' or 
'sys' module are classes that inherit from 'AppVisibleModule'. 
At wrapping-time all 'w_*' attributes are made visible on
the corresponding wrapped module instance.  Thus you can 
access the same (wrapped) object from App-Level or Interp-Level.  
There is some wrappings taking place but just look at the docstring :-)

cheers,

    holger