Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71532
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52E2C98C.6010005@lerdorf.com>
References: <CADajX4AzUWh4-DALP_-fkpfPB+CMK4NvNJ2ByzmAUz2wGW8n4w@mail.gmail.com>
 <52E29253.2000801@lsces.co.uk> <52E2924B.6080002@ajf.me> <CAMUwpuS0KzwJWO=8Pfxdfwe8BuYPcPLHTrcB7ubfafXJ2020FQ@mail.gmail.com>
 <52E299D4.6040102@garfieldtech.com> <CAMUwpuTe_ACUhznyO6c=t1kJitb=UnfR2jK9yh_HPi=QeQNzug@mail.gmail.com>
 <52E2C98C.6010005@lerdorf.com>
Date: Fri, 24 Jan 2014 23:03:05 +0200
Message-ID: <CAL0xaBHtjNMb8HCc5zMP+xQVJgSVMEtqbBX-4h_gbURTKSKxsg@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c1236a7571bb04f0bdb05f
Subject: Re: [PHP-DEV] Ruminations on PHP 5++
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--001a11c1236a7571bb04f0bdb05f
Content-Type: text/plain; charset=UTF-8

2014/1/24 Rasmus Lerdorf <rasmus@lerdorf.com>

> PHP is and should remain:
>
> 1) a pragmatic web-focused language
> 2) a loosely typed language
> 3) a language which caters to the skill-levels and platforms of a wide
> range of users
>
> The web is not typed. If we are going to expand the type checking we
> have to respect type coercion. If people can no longer do:
>
>    age_check($_POST['age'])
>
> because age_check is defined as:
>
>    function age_check(int $age) { }
>
> then we have a problem. This is why PHP doesn't have type checks for
> coercible types, of course. Many suggestions I have seen so far use the
> friendly-sounding "type hint" term to introduce strict typing. They
> aren't hints at all in those implementations. It doesn't mean we can't
> do something here, but it has to be done very carefully.
>

I've wrote a lot on that subject when the floodgates were open on the
internals. I think under type-hinting most of the people understood the
convertable type of hints, when a string is automatically converted to a
number (float or int depending on the defined typehint) and I still support
that idea. I strongly belive that those who are advocating to strict type
hints have to be banned from the list (joke!), but seriosly - as you said,
there can not be any kind of strict type hinting in PHP and I belive this
has to be declared somewhere on php.net in writing as an axiom.


>
> And rather than piling on language features with the main justification
> being that other languages have them, I would love to see more focus on
> practical solutions to real problems. The password_hash() addition in
> 5.5 is a good example of addressing a real Web problem.
>
> PDO could use some attention. For example, I've been looking at
> PDO-mysqlnd and mysqli-mysqlnd and trying to get them to share the
> underlying mysqlnd connection. Why? Because PDO has a very nice
> client-side prepare implementation which saves 2 network roundtrips per
> query over doing them server-side. But, at the same time mysqli has some
> very nice low-level features people would love to have access to. Being
> able to export the underlying PDO connection to the native API across
> all the drivers would be a significant improvement.
>

The PDO. This is something that needs so much improvement that it's
ridicilous it has survived till this time. I use Yii framework as my tool,
they use PDO as their base. I have considered many times to integrate a
mysqli to PDO wrapper to bring things like mysqli_ping, unbuffered queries
and lost more. At this point I can do without those things because I do not
have a lot of load on my projects, but they are growing and at some point
abandoning the PDO will be a nesesity due to it's lack of features.
I think PDO is a bad idea for PHP as a whole. We are better of with a
consisten API through the native drivers and maybe a PDO like thing that
gives us data objects, but still provides ability to get to the low level
stuff that is sometimes needed. PHP lately has moved to projects that
previosly where done on Java and some other move advanced tech. And lack of
frameworks using the native drivers is kind'a bad, because in really
advanced projects you have to create your own framewok...


>
> Performance is always interesting. There are plenty of places where we
> can get some performance wins, especially through tighter integration
> with opcache.
>
> Unicode Unicode Unicode.
>
> And yes, I know these are much harder and less sexy than adding a couple
> of tokens to the yacc grammar, but when we start looking at a new major
> release this is what I hear from people who are running PHP in
> production environments are looking for. Language features are nice, if
> they are well thought out, but significant infrastructure improvements
> are nicer.
>
> -Rasmus
>
>
Agree. Although I'm unable to help directly (my C is confined to some basic
Borlan C/C++ in DOS), I agree with your view absolutely.

--001a11c1236a7571bb04f0bdb05f--