| Re: getting perl and php to talk to each other [message #180601 is a reply to message #180600] |
Tue, 05 March 2013 23:59   |
Ben Morrow
Messages: 5
Registered: March 2013
Karma:
|
Junior Member |
|
|
Quoth Thomas 'PointedEars' Lahn <php(at)PointedEars(dot)de>:
> [X-Post & F'up2 comp.lang.php; please do not X-Post without F'up2]
OK. As such I won't see any replies.
> Ben Morrow wrote:
>> Quoth Cal Dershowitz <cal(at)example(dot)invalid>:
>>> [x-posted to clp.misc]
>> [...]
>>>
>>> This article has me convinced that I want perl and php able to deal with
>>> each other:
>>>
>>> http://www.linuxjournal.com/article/9282?page=0,1
>>
>> Why on Earth would you want to do that? Seriously, I can't think of any
>> situation where mixing PHP and Perl is easier than just writing in Perl
>> in the first place.
>
> Other people would say the same about writing PHP instead of a mix.
Yes, of course.
> However, there can be value in two programming languages in the same
> program. Just consider what kinds of data you can pass via the command
> line and what kinds you cannot pass that way (yes, there are text files,
> named pipes, and other equally ugly workarounds).
The methods used by PHP::Interpreter are not really any less ugly. Until
you get to the point of being able to run the two languages on the same
VM with properly interworking data structures (such as Parrot is trying
to achieve, for instance) I don't see much point stuffing the two
languages into the same process and then just passing strings to eval
back and forth.
>> Note that the Perl in that article (or at least, the first page, which
>> was all I read) is pretty bad:
>>
>> […]
>> - using PHP to talk to a database, when Perl's DBI module is
>> considerably better than PHP's rather random database functions.
>>
>> I don't know PHP well enough to comment on it,
>
> Yet you did, which shows that you have never used PHP Data Objects (PDO).
> “*Random* database functions”? IBTD.
I have not. The database functions used in the article referenced were
mssql_connect and so on, which last time I used PHP (a long time ago)
was all there was. I don't think you can deny that *those* functions
(and the equivalent set for other databases) are a nasty mess. I tried
to make it clear that I understand the state of the PHP art has improved
since then.
My major point was that I don't see any good reason to call into PHP
just to connect to a database, when Perl already has perfectly good
database code. Had the example been written the other way around the
equivalent point could of course have been made about calling into Perl.
>> but I wouldn't be surprised if the PHP code was just as bad (for instance,
>> I understand PHP has a saner database interface these days; I don't know
>> if it existed in 2007, though).
>
> It did; for example, “PDO [shipped] with PHP 5.1”, “[r]eleased: 24 Nov
> 2005”, which is not that hard to find out:
Not that hard had I been interested, which I'm not, and had I known
'PDO' was the term to look for, which I didn't. (I was actually thinking
of the PEAR DB module, which I've observed is a thing that exists.
Again, I've no idea if this is the currently-recommended database
interface, or how it compares with the Perl DBI.)
Ben
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]