Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:8312
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net
Date: Tue, 2 Mar 2004 18:11:04 +0100
User-Agent: KMail/1.5.4
References: <5.1.0.14.2.20040302000350.0272fc70@127.0.0.1>
In-Reply-To: <5.1.0.14.2.20040302000350.0272fc70@127.0.0.1>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200403021811.04822.cyberian@arcor.de>
Subject: Re: [PHP-DEV] Perl extension
From: cyberian@arcor.de (Kai =?iso-8859-1?q?Schr=F6der?=)

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