Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48033
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.215 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=Ko/yUIHSTfTRmYRCVnCHosv2TUdLw/f8kdHLjx2D83QJ4DLbXMtz1bGn3APQRfQIB2
         thbPwpO/j2D0xrNzN7FnXfnZhhK9AwsPtenUErM01RI6QE7e7edi9BqUkwoiTAWarMkg
         Sevdbaf1lMhfsX715mie5yGvfrxsKd4AAq3gs=
MIME-Version: 1.0
In-Reply-To: <4BCE44B8.6060600@zend.com>
References: <t2y294a23a11004200739v6b3e18f1z52abfa89db643a09@mail.gmail.com>
	 <4BCE44B8.6060600@zend.com>
Date: Wed, 21 Apr 2010 12:46:23 +0300
Message-ID: <w2z294a23a11004210246z2ee90c87h57cf322a92591f7f@mail.gmail.com>
To: Stanislav Malyshev <stas@zend.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=0016364169e72c4e600484bc1134
Subject: Re: [PHP-DEV] A critique of PHP 6
From: adi.nita@gmail.com (Adi Nita)

--0016364169e72c4e600484bc1134
Content-Type: text/plain; charset=ISO-8859-1

Hi,

On Wed, Apr 21, 2010 at 3:20 AM, Stanislav Malyshev <stas@zend.com> wrote:

Come on. Is it really that hard to write strlen? Or array_merge? Would it be
> better if they were len (of what?) and merge (what?)? I don't think so.


I think you missed the point when I said we should use system namespaces.
There are several ways in which to use namespaces, including aliasing.


>
>  procedural-style PHP. But now we have namespaces, that were introduced
>> exactly for this kind of situations. Why not take advantage of it? PHP can
>>
>
> Nope. The namespaces were introduced to manage deep and wide class
> hierarchies, especially large frameworks with hundreds of classes, not to
> bother little string functions that never hurt anyone.
>
>
You know, there is a world out there too, outside the "deep and wide class
hierarchies". I really doubt that namespaces were introduced in the language
with the sole purpose of grouping hundreds of classes. But you can, if you
make everything a class.


>
>

>  2. TYPE HINTING. Currently PHP supports argument type hinting for arrays
>> and
>> objects. As I know, it's also been decided to offer support for this in
>> function return values. For me it is hard to understand why not offer
>>
>
> Decided by whom? When?
>
>
Here
http://www.php.net/~derick/meeting-notes.html#type-hinted-properties-and-return-values.
But this may be outdated, sorry if I may not know well.


>
>  code coincides with the global namespace ( \ ) code, I think it's safe to
>> remove the *define* function and possibly allow the *const *keyword to
>> define runtime constants as well (when the value is not a constant
>> expression).
>>
>
> That would not work since code can not be run when class is being parsed,
> and after that it is not clear when it is supposed to be run and in what
> context, etc. But more importantly - what for? If you need to calculate
> something, make it a variable and calculate it in the ctor. Constants aren't
> meant to be results of complex calculations, they are meant to be simple and
> fixed.
> There was a proposal for read-only variables and one for per-variable
> getters/setters (actually, with some effort you can do it right now, a bit
> less efficiently maybe but doable). This might be direction to go in this
> case.
>
>
When I said global namespace, I meant outside any class as well, where we
would normally use *define*. My focus was that constants are not meant to be
nor simple, nor complex, but just... constant. I cannot use a variable
computed in the ctor or anywhere else, because that would not be constant.
Simulating readonly properties with a combination of private access and a
magic getter is probably a good example of bad code.


>
>  4. PARAMETER ORDER. As noted in an older PHP meeting:
>>
>
> Two letters: BC.
> Changing variable order in an existing function is a big fat BC break. And
> if we put such a bomb into a new version, what would be the incentive for
> people to use it? So that apps would have to be shipped in 2 versions, for
> the old php and the new php?
>
>
What you call a bomb, I call a fix in the language. People should use it
because it is better, not because it is "more". Current apps are shipped in
two versions, for both PHP 4 and 5? No. Take a look at Python 3 for another
example. In the long run, it's more acceptable to break some code once with
a new feature (and devs will know why and what to fix), than have the code
break itself over the time due to bad design.


>
> Please remember - what you call "ancient code" other people call
> "application on which my paycheck depends". So I think we should be
> super-extra-careful when messing with it. That doesn't mean we would never
> do any BC-breaking change ever - that does mean there always has to be a
> very good reason for it. And I personally don't see "consistency" being good
> enough reason. Don't get me wrong - it's good, it's just not good enough to
> be valued over working applications.
>

I totally agree with the phrase "application on which my paycheck depends".
But applications are developed, fixed and maintained, they are not static,
nor statues that we stare at. I cannot agree with the idea of preferring
working applications to good working applications. Our main focus here is
the language and developers' main focus is their applications.

So, indeed, my opinion is that PHP should take several design decisions in
the future even though some are bolder than others, because I believe
applications will benefit from this in the long term. I don't refer to the
proposals above, but to any solid change that deserves a chance. With
breaking code in mind, we'll have only things added up and end up with a
much bigger and only slightly better PHP.

--0016364169e72c4e600484bc1134--