Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Anyway, so much for the 'outside world' view of objects as black box things that have properties and methods.
[ ... ]
Almost everything we do here is going to be with method calls. There's very little that I can see that requires any faster access than that, so as long as we have a proper protocol that everyone can conform to, we should be OK.
The distinction object vs class is still in the way a bit, when it comes to method calls.
$ python ...
i = 4 i.__sub__(1)
3
help(int)
... | __sub__(...) | x.__sub__(y) <==> x-y
Given that a PyInt is just a PMC it currently needs a lot of ugly hacks to implement the full set of operator methods. dynclasses/py*.pmc is mostly just duplicating existing code from standard PMCs.
Iff the assembler just emits a method call for the opcode:
sub P0, P1, P2
we have that equivalence too, with proper inheritance and static and dynamic operator overloading.
I've duplicated FixedPMCArray.get_pmc_keyed_int() as a method, starting with this line:
METHOD PMC* __getitem__(INTVAL key) {
Point of order: discussions would be a lot easier if they didnt *start out* with perjorative terms like "ugly hacks". One of my goals is to eliminate the need for if (!Interp_flags_TEST(INTERP, PARROT_PYTHON_MODE)) sprinkled throughout the various "standard" (i.e. Perl) PMCs.
Yes, this all needs to be radically refactored - and all perlisms and pythonisms removed from the "standard" classes.
Meanwhile, feel free to ask questions or make suggestions.
With that out of the way, I will assert that in all the Python code I have seen, use of infix operators and square brackets for indexing overwhelmingly dominate direct use of the methods. Furthermore, it is clear that operators like "sub_p_p_p" and "set_p_p_kic" will always perform better than callmethodcc_sc "__sub__" and callmethodcc_sc "__getitem__" respectively.
Therefore, Pirate emits the opcodes whenever direct use is made of things like infix operators and square brackets. And implemented methods like __sub__ which, while rarely used, will operate correctly by invoking to the opcodes.
I *don't* see a need to heavily optimize for rarely used mechanisms.
I encourage you to check out Pirate. The IMCC output of pirate.py is now remarkably close to the output of pie-thon.pl.
- Sam Ruby
