[Argh...]
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> parrot_alias(a, 'b', # dest: Python is unified, no need for a
> category here
> a, 'b', 'scalar') # src: Perl is not unified, so source category
> is required
>
> parrot_alias(a, 'c',
> a, 'c', 'array') # here's a different category, to get '@c'
>
> or some such. Yes it's ugly. But if we can't fix a ditch, the least
> we can do is put a big friendly warning sign on it.
It seems to me that a much easier way to handle this would be to
mangle Perl variables to something that most languages *can* access:
$foo=s_foo
@foo=a_foo
%foo=h_foo
&foo=f_foo (for function)
::foo=n_foo (for namespace)
Yes, n_File.n_Path.f_new() is uglier than File.Path.new, but at least
there's no ambiguity.
Another way to do it would be to have each "category" actually be a
namespace. In other words, Perl's namespaces are structured like
this:
File => package {
ns => package {
Find => package {
sub => package {
find => { ... }
}
},
Path => package {
sub => package {
BUILD => { ... },
DESTROY => { ... }
}
}
...
},
scalar => package {
some_idiot => "put a variable in this package"
}
}
And Python would access them like so:
File.ns.Path.sub.new()
Not perfect, certainly, but it would work, and be reasonably elegant.
(This does pose a problem going the other way, but I suspect Perl
could simply mark its own packages in some way, and fall back to a
simpler scheme, such as "ignore the sigil", when it's munging another
language's namespaces.)
--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
There is no cabal.
[I currently have a couple Gmail invites--contact me if you're interested.]
--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
There is no cabal.
[I currently have a couple Gmail invites--contact me if you're interested.]
