Ben Morrow wrote:
> Quoth Thomas 'PointedEars' Lahn <php(at)PointedEars(dot)de>:
>> Ben Morrow wrote:
>>> 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.
Most certainly I deny that. I agree that several of those functions are
unsafe, and it is unfortunate that the order of arguments for MS SQL is
different than, for example, MySQL. But IMHO that is still a long way from
“a nasty mess”. They have been used and have worked for the better part of
a decade. After all, they have helped to build the Web that we have today,
so they cannot be all bad, can they?
AFAIK the first step towards a better interface (with support for Prepared
Statements) was mysqli by MySQL AB, now Oracle, with PHP 5.0 or later. Then
came PDO and others.
> I tried to make it clear that I understand the state of the PHP art has
> improved since then.
The state of the PHP art as the article suggests was even better back then.
You should not assume that the quality of PHP code as it can be found in
such articles, in blogs, and Web forums reflects the quality of the
programming language at the time. In fact, you would do well to assume that
it reflects the exact opposite. The same is true for other (overly)
beginner-friendly languages, for example ECMAScript implementations like
JavaScript. (And if you know that ECMAScript and its implementations as
well as PHP range among my favorite languages despite their flaws, you also
know that I do not make such statements lightly.)
> 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.
Please don't play stupid with me. That section is part of a chapter of the
PHP manual about several database interfaces.
> (I was actually thinking of the PEAR DB module, which I've observed is a
> thing that exists.
Many things exist on PEAR, written by third parties, some with stupid
interfaces; the same was as many things exist on CPAN, some with stupid
interfaces.
<OT>
For example, I remember Number::Format from CPAN to be particularly stupid
with regard to locales:
my ( $thousands_sep, $mon_thousands_sep, $grouping, $decimal_point ) =
@{ localeconv() }{ 'thousands_sep', 'mon_thousands_sep', 'grouping',
'decimal_point' };
# Apply defaults if values are missing
$thousands_sep = $mon_thousands_sep unless $thousands_sep;
$thousands_sep = ' ' unless $thousands_sep;
# grouping and mon_grouping are packed lists
# of small integers (characters) telling the
# grouping (thousand_seps and mon_thousand_seps
# being the group dividers) of numbers and
# monetary quantities. The integers' meanings:
# 255 means no more grouping, 0 means repeat
# the previous grouping, 1-254 means use that
# as the current grouping. Grouping goes from
# right to left (low to high digits). In the
# below we cheat slightly by never using anything
# else than the first grouping (whatever that is).
my @grouping;
if ($grouping)
{
@grouping = unpack( "C*", $grouping );
}
else
{
@grouping = (3);
}
## FIXME: Why don't the defaults work already?
my $formatter = new Number::Format(
-decimal_point => $decimal_point,
-thousands_sep => $thousands_sep,
-kibi_suffix => ' KiB',
-mebi_suffix => ' MiB',
-gibi_suffix => ' GiB',
# -grouping => $grouping[0]
);
echo $formatter->format(421337);
----
Does that not qualify as a “god-awful mess” for you for something so basic
such as formatting numbers? [It is not really better in PHP with
number_format(), though. Apparently, despite its obvious importance – what
have *computers* originally been built for? –, easy and proper number
formatting, and string formatting in general, apparently is not on the list
of priorities in many programming language designs. As if many language
designers subscribed to the paradigm ”Who cares? Let the developer reinvent
the wheel over and over again” :-/]
</OT>
> Again, I've no idea if this is the currently-recommended database
> interface, or how it compares with the Perl DBI.)
I can recommend it from professional experience, because it is a very clean
and efficient, object-oriented, easily customizable, and rather compatible
interface. Zend Framework uses it by default, for example. Which allows
you in many cases just to switch the database adapter if you switch the
DBMS. (In case you do not know, the people who wrote/write the PHP VM are
at Zend.)
So I can only strongly suggest again that you RTFM and STFW before you make
any statement about languages that you say (or think) you do not know well
enough to make statements about, unless you want to make a fool out of
yourself.
HTH
PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14
|