On Monday 01 March 2004 23:10, Andi Gutmans wrote:
> Hey,
> As some of you might have noticed, Dmitry worked on a Perl extension which
> allows PHP to run Perl scripts as well as instantiate Perl objects in PHP
> and use them.
Intresting idea, but I have some questions:
- Should ext/perl "only" bring CPAN modules into PHP or is the goal to run any
Perl code in PHP?
- Why ext/perl and not ext/parrot? Sterling started some experiments with
Parrot last year, why not go this way? Yes, I know that Parrot is far away
from a final release, but do we really need Perl support in PHP now?
> The main problem with the extension is the fact that Perl functions behave
> differently according to their context (scalar/array) which doesn't exist
> in PHP. We thought of all sorts of ways to solve this problem but aren't
> sure what the best approach would be.
That is the problem of the Perl C API, but you will get more problems too. In
Perl you have 3 variable types: scalars (string, integer, float, ...), arrays
(lists without holes and numeric keys) and hashes (assoc array is nearly the
same in PHP). Both, Perl arrays and Perl hashes, you have to map to PHP
arrays, but where is the point to differ between a list and an assoc array?
Simple example:
In Perl ('a' => 'b', 'c' => 'd') could be an assoc array with 2 elements
(hash) or a list with 4 elements (array, elements on odd positions are the
old keys).
My idea:
perl_declare_as_scalar
perl_declare_as_array
perl_declare_as_hash
Now the PHP variable knows (internal) what Perl variable type it should have.
Other problems I see:
- Perl scalars could be references to anything (for instance on variables
inside a sub/function)
- Perl have tie (bind a variable on a package and do magic things like
automtic sort lists, share variables between processes, ...)
- Perl have an good working own Garbage Collection, do you really want to
manage memory manually?
- In Perl $var, @var and %var are different things (same name, but different
prefix and variable type)
- Is the Perl Artistic License compatible to the PHP License?
> As it's in pecl it doesn't have to be finalized quickly but it would be
> nice to have something working for PHP 5's release (via pecl).
-1000 for that. Please make PHP5 first, what PHP4 was and is: stable and fast.
Than start again with implementing new features. Only morrons will invest in
a beta language because the buzzword list is long.
PHP doesn't need Perl support really, it is only nice to have. The other (and
imho better) way is to motivate PEAR developer more, than you don't need to
assimilate CPAN code. And again: take some minutes to think about PHP for
Parrot.
Regards, Kai
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
