At 10:37 AM -0500 2/4/03, Phil Hassey wrote:
List,PHP's going to have a problem there. If it calls $foo->bar, and $foo has a Bar method instead (or, worse, a Bar and BAR method) then the call will fail. Not much we can do, unfortunately.
I've been lurking here for about two months, after having read the summaries
for several months previous. I'm interested in parrot because 1. I want it
very badly for php / python / perl combinationability(?) 2. Just reading
about the project is a fascinating learning experience.
I've looked over the parrot docs on parrotcode.org, and have a few questions
/ concerns. Most of my problems lie within the fact that I'm so interested
in seeing php / python / perl coexisting peacefully.
1. Function case -- some languages like php don't use case for function or
method names. Thus $a->toString(); is the same as $a->tostring(); However,
a language like java does care. How will php be able to call the correct
java method? I suspect one solution for php would be to have a way to do a case
insensitive method lookup.
Being able to share variables across language code is one of the big things we're working on. It should be fine, and since all the language routines will ultimately be working on parrot's low-level string type it's just a matter of getting the right bits out of existing variables via a predefined interface. Shouldn't be a problem.2. Strings -- everyone deals with strings differently. There was some allusion to this issue in the docs on parrotcode.org, although the question wasn't quite answered. I also might not have quite understood the vtables chapter... So if I create a perlscalar string, and send it to a python function, what happens? Does the string act like a perlscalar or a pythonString? Or if I cared one way or an other, could I force it to switch to being a pythonString or stop it from switching? I suspect a language like PHP wouldn't have too much trouble with dealing with foreign strings, as it uses functions, and if all strings were a subclass of some parrotString class, PHP could handle them. But when a php string was sent to python or perl, that string would have no methods at all (except for maybe the parrotString methods?) The more fundamental question is -- is it possible to (if requested) magically transform one object to another type -- but only while it's in a different languages context? I suppose multi-threading would make the issue even more confusing...
Kinda hand-wavey, but I'm way behind and trying to answer quickly. Sorry... :)
Oh, and where's #3? It's gone missing.
We'll probably do some sort of namespace isolation, but if you use php code, it'll make sure the base php libraries are pulled in. Some of the more internals-oriented stuff, like walking attribute spaces on objects and such, may not work the same when running on parrot, though we'll be able to translate or thunk a lot of that sort of code.4. Global Scopes -- each language has its own idea of what is part of the core function/pre-defined values set. If I start a python script, and call a php script, will php have python's global core (__import__,apply, compile,complex,xrange, etc...) or will the php script have the usual myriad of php functions available (all 5000 of them)? I guess when I'm in a php or python context, I'd want things to feel like a php or python context... Maybe each language gets its own namespace? php::main, python::main...
BTW -- is anyone working on php->parrot right now? I saw a mention of it a few weeks ago, but no links..
I don't think anyone's working on it at the moment, but I might be wrong.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
