Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50451
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.185 as permitted sender)
To: Derick Rethans <derick@php.net>
CC: Felipe Pena <felipensp@gmail.com>, internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] Hold off 5.4
Thread-Index: AQHLiq41Ol2hxdT5ykGg55EmaGXJcZN+stQAgAA0jnCAABB0gIAAIsvw
Date: Tue, 23 Nov 2010 14:21:29 +0000
Message-ID: <887FE7CFF6F8DE4BB3A9535F53AFD06A2C5C6157@il-ex2.zend.net>
References: <AANLkTi=coWEEMNnr_SsTCo7HaXUPRwcJg7fUz=NjA8nq@mail.gmail.com>
 <alpine.DEB.2.00.1011230945310.24401@kossu.derickrethans.nl>
 <887FE7CFF6F8DE4BB3A9535F53AFD06A2C5B099F@il-ex2.zend.net>
 <alpine.DEB.2.00.1011231400010.24401@kossu.derickrethans.nl>
In-Reply-To: <alpine.DEB.2.00.1011231400010.24401@kossu.derickrethans.nl>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: [PHP-DEV] Hold off 5.4
From: zeev@zend.com (Zeev Suraski)



> > For the record, I'm still very uncomfortable with this new language
> > syntax - even if it's a no-op right now.
>=20
> I know you are; but from what I understood, there were no more comments
> to the latest mail (with patch and RFC) that I've made towards this.

I know, I took some time off after reaching agreement we're not going to ad=
d strict checks - but I said from the get go that it's questionable whether=
 we should add this syntax.

>=20
> I'm not comfortable about not having the proper strict checks that we had=
.=20

Except we never had them.  It's like me committing support for inline assem=
bly syntax or whatever other weird idea I might come up with, and then sayi=
ng I don't feel comfortable about removing it.  With such fundamental chang=
es there should be a very broad support, with the status-quo being the defa=
ult in case no such broad support is reached.  The status quo is not the la=
test state of trunk, but rather, the state of previous versions.

> It seems we're both having to live with something uncomfortable.

We should attribute as much importance to adding features as removing featu=
res;  Can I jump ahead and remove this support in trunk, and get back to yo=
u with 'one of us will have to feel uncomfortable' feedback?  I don't think=
 it works that way.  The status quo, and the way PHP existed since forever,=
 is no strict type checking or syntax for supporting it.  IMHO before there=
's a clear informed decision to change that, it should stay that way.

With the kind of phpdoc updates we're likely to add, you should be able to =
implement your extension-level support on top of this meta data.  The chanc=
es of that becoming mainstream and creating two flavors of PHP are much sli=
mmer which make it a much better fit than a big chunk of language level syn=
tax that's a no-op by default.

> > Are we effectively going to create the original type checking
> > implementation, but in a separate component people would have to
> > install - thereby creating two very different flavors of PHP?
>=20
> It's clearly a debugging aid for me. So this should be in a debugging
> extension. I doubt any sort of shared hoster would install it, but it
> *does* give people the power to do this for their own controlled set-up.
> Also, if the extension is suddenly not there, the app will still work so =
I am not
> buying your "two flavours" argument.

It may or may not work depending on how you write your code.  If you rely o=
n that feature your app may very well stop working properly (e.g. it may ex=
pose it to security issues).
It's very much creating two flavors.

> > Regarding the alpha release, I think there are two key issues here:
> >
> > 1.  Does this alpha mean anything at all.  Some, myself included,
> > don't feel comfortable about the state of certain things in the
> > current codebase (example given above).  Are we all in sync that even
> > if a certain feature makes it into the alpha, it doesn't mean that it
> > won't be removed or be severely modified in an upcoming beta/GA?
> > Is it clear it has no implications on when the final release would be?
> > That is, at least, the way I perceive alpha releases.  In which case
> > it's not exactly clear to me what the benefits of releasing an Alpha
> > in this day and age for PHP - where we have snapshots every few hours.
> > We need to have a very clear understanding of what this does or
> > doesn't mean, and make sure we communicate it properly to the users.
>=20
> To me this alpha would be a "this is what we're mostly likely going to ha=
ve
> thing". I wouldn't like to see new major features, engine rework being do=
ne;
> but I also think we shouldn't try to remove stuff from it unless really
> necessary.

If that's the case, count me in those who oppose the release of the current=
 codebase as an alpha.

Zeev