Another one wiped out by Thunderbird crash.
tewk wrote:
Allison Randal wrote:
tewk wrote:
Patch was to large to attach so: http://tewk.com/pdd15_testing.diff
Tests currently fail because they use the "new" opcode to instantiate
objects.
Fixing the 'new' opcode is the first change we need to make to get
both object models working simultaneously. Pick one:
- The 'new' opcode can no longer lookup string class names by type
number (eventually true).
I'd really like to work on permanent solutions.
We are working on permanent solutions, we're just moving there by a
process of refactoring. Removing the type number system from Parrot is
too extensive a change to be the first step in integrating the new
object system. (This is what we'll need to do to make this
implementation path work.)
So, for now we go with:
>> - The PDD 15 object implementation needs to register a type number for
>> its classes (as a temporary measure to smooth over integration).
So how should we
implement option one?
Should we have a pmc lookup resolution order of current namespace, hll
namespace, parrot namespace, and finally root namespace.
Then all current, non-hll pmcs should be placed in the parrot namespace.
Nope that won't work, the parrot and root namespaces can't blead into
hll namespaces' visibility.
We really need independent opcodes which segment the current namespace,
hll namespaces, and the root parrot namespace.
I think we should have:
new_cur - resolves using the current namespace
new_hll - resolves pmcs and classes using the hll namespace
new - resolves using the parrot namespace.
we probably need the same thing for newclass.
newclass_cur
newclass_hll
newclass
I'm more inclined to stick with new and newclass, and just provide
namespace options as flags.
Second issue:
PDD15 registers methods in the class. So methods defined using :method
in the class namespace aren't found by the find_method.
So:
1: We force compiler writers to make add_method calls for every method
and drop :method
Definitely not.
2: After running :init and :load subs we auto-call add_method for
methods defined in pir with :method. (this has nasty corner cases)
What do we do about evaled :methods, repeat the same auto-call
technique after ever eval?
Close.
3: We modify the Class PMC's find_method to look in the namespace for
method and lazily call add_method.
Not really desirable.
4: The call to newclass checks the namespace associated with the class
to see if it contains any :methods or :vtables. If it does, it
automatically adds them to the class. (This covers the case where the
methods were loaded before the class was created.)
Also, the code that installs subs in a namespace checks to see if that
namespace is associated with a class, and if it is installs any :method
or :vtable entries in the class. (This handles methods loaded after the
class is created, and evals.)
There will still be some methods that need to be manually installed with
add_method.
Allison
