Sam Ruby <[EMAIL PROTECTED]> wrote: > Leopold Toetsch wrote: >> What is unclear about: "This just moves the burden of doing a method >> call down to all classes and doesn't really fix anything."?
> First you state "The "f" object (the method call stub) has to > shift up call arguments and place the object as the first argument." Yes. See another message I've posted WRT that. > In other words, moving the burden of doing the marshalling of parameters > down to the class really *does* fix something. Er, no. Because whatever you do, your (anybodies) HLL compiler will just emit a plain function call in that case. Your proposed call_method vtable doesn't cover it all. So just pushing down the problem to *all* classes that implement function or method calls doesn't help. Parrot itself has to deal with it. > Then you state that moving the burden in a similar case doesn't fix > anything. Yes, because it is *not* python-specific. We've to approach a common solution for all supported languages. >>>Whatever. >> >> Again: the problem is *not* python-specific. > Analogy: is classes/string.pmc Perl Specific? People including me have submitted lot of patches to get Perl* out of core PMCs. So string.pmc should end up in a usable base for many string functions. > I anticipate each language will need a language specific string class. > Hopefully each will inherit much of their functionallity from Parrot's > string class once all the multiple inheritance and MMD issues are worked > out. Exactly that's the goal. Inheritance, code reuse, interoperbility. > In a similar manner, I expect many languages will need a language > specific "class" class. Again, hopefully each will inherit much of > their functionallity from a Parrot "class" class. Well, the "class PMC" aka the metaclass of the class system is much more HLL specific. Not much can be inherited here. All that's not inheritable has to be done in vtable methods. > ... That's why it is nice > that VTABLE_get_attr_str is a VTABLE entry and not hardwired into > Parrot_getattribute_p_p_sc. This nicety is coming from my desire for abstraction. I thought, it'll be needed. I've written & committed these patches (against Dan's wishes...) > In a similar manner, I expect most languages to implement call_method to > either simply inherit the default or to implement the same basic flow of > find_method followed by invoke. I'm fully in accordance with you up to here. But argument passing and method calls isn't currently in sync - Parrot is doing different things then HLLs are doing. Before this isn't fixed (and it needs fixing) I can't and won't go any further. *If* then something isn't working for Python or whatever language, we can look for a more generic way. And argument passing and method or function calls isn't really a python-only language feature. First Parrot needs to adhere to HLL semantics. > ... What is in between those two calls, > however, may vary based on language - for example, what exception is to > be thrown if the method is not found may vary from language to language. These are minor problems. They have to be solved, as well as creating a HLL specific destination PMC in infix methods. First we've to fix the basics. > However, I can't override this behavior if it remains hardcoded in the > op. We can throw a language-sepcific exception. You can translate the exception type. There are many ways to address such problems. Later. > - Sam Ruby leo
