On 6/17/05, Sebastian Mendel <[EMAIL PROTECTED]> wrote:
> > Besides, the point of E_STRICT seems to be to _enforce_ best practices
> > -- and if you care about this matter, considering all members as
> > "public" is probably defying the concept anyway.
>
> but defining all as public doesnt produc
Nelson Menezes wrote:
> On 6/16/05, Johannes Schlueter <[EMAIL PROTECTED]> wrote:
>> On Thursday 16 June 2005 11:27, Sebastian Mendel wrote:
I guess, this will more likely produce an error message like this:
Parse error: syntax error, unexpected T_PUBLIC, expecting T_STRING in
On Thu, 16 Jun 2005, Zeev Suraski wrote:
> At 18:30 16/06/2005, Rasmus Lerdorf wrote:
> >Derick Rethans wrote:
> > > Hello,
> > >
> > > after reading this very long thread, and problems with having the public
> > > keyword I decided not to allow any kind of forward compability to be
> > > introduc
At 18:30 16/06/2005, Rasmus Lerdorf wrote:
Derick Rethans wrote:
> Hello,
>
> after reading this very long thread, and problems with having the public
> keyword I decided not to allow any kind of forward compability to be
> introduced into PHP 4.4. Discussion is over.
Yeah, I think the change re
Derick Rethans wrote:
> Hello,
>
> after reading this very long thread, and problems with having the public
> keyword I decided not to allow any kind of forward compability to be
> introduced into PHP 4.4. Discussion is over.
Yeah, I think the change really needs to be in PHP5 instead. Right n
Hello,
after reading this very long thread, and problems with having the public
keyword I decided not to allow any kind of forward compability to be
introduced into PHP 4.4. Discussion is over.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Intern
I completely agree. This (or any other "public-in-4.4" solution) would
only create an extra branch to maintain for both developers and users;
no one can expect all of the PHP 4.x base to go 4.4, and code with
"public" that "supports php 4 and 5" would actually break in 4.<4 and
still would be:
- u
On Thursday 16 June 2005 11:27, Sebastian Mendel wrote:
> > I guess, this will more likely produce an error message like this:
> >
> > Parse error: syntax error, unexpected T_PUBLIC, expecting T_STRING in
> > public.php on line 2
right
> > So I'm strongly against this change. If you want to run P
Hi Sebastian,
On Thursday 16 June 2005 11:16, Sebastian Mendel wrote:
> > err no .. because that would break existing php 4 code in 4.4
>
> what exactly? the new error-level? the message with this new
> error-level? or the dummy-keyword?
>
> sorry but i didnt see this.
That an error, which isn't
Stephan Schmidt wrote:
> Hi,
>
> Lukas Smith wrote:
>> I think its a good idea to have, to make it somewhat possible to
>> prepare for the PHP5 E_STRICT world, while still developing PHP4
>> compatible code. I could for example see this help increase the PHP5
>> adoption inside PEAR, since this wo
Lukas Smith wrote:
> Sebastian Mendel wrote:
>
>> and is it a problem to implement such a new error level also with PHP
>> 4.4. for example reporting overwriting $this is not allowed in PHP 5 ?
>>
>> and, when we are at this, what about 'clone' as a dummy-keyword in PHP
>> 4.4 ?
>
> err no .. bec
Hi,
Lukas Smith wrote:
I think its a good idea to have, to make it somewhat possible to prepare
for the PHP5 E_STRICT world, while still developing PHP4 compatible
code. I could for example see this help increase the PHP5 adoption
inside PEAR, since this would allow us to make some packages E_
Sebastian Mendel wrote:
and is it a problem to implement such a new error level also with PHP
4.4. for example reporting overwriting $this is not allowed in PHP 5 ?
and, when we are at this, what about 'clone' as a dummy-keyword in PHP 4.4 ?
err no .. because that would break existing php 4 c
Mike Bretz wrote:
> Rasmus Lerdorf wrote:
>
>> What was the reasoning again for not having var be a synonym for public
>> in PHP5? It is a bit annoying that a simple PHP4 class using var throws
>> a notice in PHP5 when there is technically nothing wrong with it.
>>
>> -Rasmus
>
> I personally do
Stanislav Malyshev wrote:
> SM>>> Here's something I am missing - if you say notices are so much rpoblem,
> SM>>> why not remove them?
> SM>>
> SM>>oh, PHP introduced NOTICEs so that i remove them? great ...
>
> But that's _exactly_ what is proposed - to add a keyword to PHP to
> only to remove
Rasmus Lerdorf wrote:
> Lukas Smith wrote:
>
>>Stanislav Malyshev wrote:
>>
>>
>>>I wonder what was the original purpose of PHP5 emitting warning when
>>>seeing 'var'? What are you basically saying now is "I want PHP4 code
>>>that wouldn't have messages on my class vars if run in PHP5". But I'm
>>
Lukas Smith wrote:
> Stanislav Malyshev wrote:
>
>> I wonder what was the original purpose of PHP5 emitting warning when
>> seeing 'var'? What are you basically saying now is "I want PHP4 code
>> that wouldn't have messages on my class vars if run in PHP5". But I'm
>> sure there was some idea behi
Lukas Smith wrote:
Stanislav Malyshev wrote:
I wonder what was the original purpose of PHP5 emitting warning when
seeing 'var'? What are you basically saying now is "I want PHP4 code
that wouldn't have messages on my class vars if run in PHP5". But I'm
sure there was some idea behind these wa
Stanislav Malyshev wrote:
I wonder what was the original purpose of PHP5 emitting warning when
seeing 'var'? What are you basically saying now is "I want PHP4 code that
wouldn't have messages on my class vars if run in PHP5". But I'm sure
there was some idea behind these warnings, not?
There
No strong reason. It was meant to help people find var's so that they can
be explicit about the access modifiers. This is why it was put in E_STRICT.
It's meant to be more helpful and informational messages, and you shouldn't
run your website in E_STRICT. Maybe the difference here are the
expec
On Wed, 2005-06-15 at 13:21, Rasmus Lerdorf wrote:
> Andi Gutmans wrote:
> > Personally, I don't think there's a significant benefit to adding
> > support for public. There are so many differences and new features that
> > the gain of just being able to change "var" to "public" would be
> > margina
Rasmus Lerdorf wrote:
What was the reasoning again for not having var be a synonym for public
in PHP5? It is a bit annoying that a simple PHP4 class using var throws
a notice in PHP5 when there is technically nothing wrong with it.
-Rasmus
I personally don't support "forward compatibilit
Andi Gutmans wrote:
> Personally, I don't think there's a significant benefit to adding
> support for public. There are so many differences and new features that
> the gain of just being able to change "var" to "public" would be
> marginal at best.
>
> That said, I don't mind supporting if people
Personally, I don't think there's a significant benefit to adding support
for public. There are so many differences and new features that the gain of
just being able to change "var" to "public" would be marginal at best.
That said, I don't mind supporting if people think it will help. It's a
t
Stanislav Malyshev wrote:
> LS>>
> LS>>A while ago someone on IRC suggested that it might be a good idea to add
> LS>>"public" to PHP 4.x for forward compatibility. I brought it up again on
> IRC
> LS>>yesterday and several prominent members of the php core community said it
> LS>>would be a good
SM>>> Here's something I am missing - if you say notices are so much rpoblem,
SM>>> why not remove them?
SM>>
SM>>oh, PHP introduced NOTICEs so that i remove them? great ...
But that's _exactly_ what is proposed - to add a keyword to PHP to
only to remove notices that PHP produces.
--
Stanisla
Stanislav Malyshev wrote:
> SM>>IMHO is 'var' the only thing that produces NOTICES in PHP 5 what can
> SM>>not be changed if this app should run in both Versions 4 and 5,
> SM>>others, like '= new' and '=& new' can easily be adopt by just removing
> SM>>the '&' without getting any NOTICE in any
SM>>IMHO is 'var' the only thing that produces NOTICES in PHP 5 what can
SM>>not be changed if this app should run in both Versions 4 and 5,
SM>>others, like '= new' and '=& new' can easily be adopt by just removing
SM>>the '&' without getting any NOTICE in any VERSION
Here's something I am mis
Pierre-Alain Joye wrote:
>>> LS>>I think its a good idea to have, to make it somewhat
>>> LS>>possible to prepare for the PHP5 E_STRICT world, while
>>> LS>>still developing PHP4 compatible code. I could for example
>>> LS>>see this help increase the PHP5 adoption inside PEAR,
>>>
>>> Like, PEAR w
On Wed, 15 Jun 2005 16:36:38 +0200
[EMAIL PROTECTED] (Lukas Smith) wrote:
> Stanislav Malyshev wrote:
>
> > LS>>I think its a good idea to have, to make it somewhat
> > LS>>possible to prepare for the PHP5 E_STRICT world, while
> > LS>>still developing PHP4 compatible code. I could for example
>
LS>>
LS>>A while ago someone on IRC suggested that it might be a good idea to add
LS>>"public" to PHP 4.x for forward compatibility. I brought it up again on IRC
LS>>yesterday and several prominent members of the php core community said it
LS>>would be a good idea to add to the 4.4 branch.
Why it
Stanislav Malyshev wrote:
LS>>Currently PEAR.php requires PHP 4.2.
This means there are a lot of people using PEAR with PHP 4.3 and 4.2. And
there's almost no people using it with 4.4 - since 4.4 is not
out. So now you want to go out and tell them "upgrade your hosting to our
brand-new PHP v
LS>>Currently PEAR.php requires PHP 4.2.
This means there are a lot of people using PEAR with PHP 4.3 and 4.2. And
there's almost no people using it with 4.4 - since 4.4 is not
out. So now you want to go out and tell them "upgrade your hosting to our
brand-new PHP version risking breaking exist
Stanislav Malyshev wrote:
LS>>I think its a good idea to have, to make it somewhat possible to prepare for
LS>>the PHP5 E_STRICT world, while still developing PHP4 compatible code. I
LS>>could for example see this help increase the PHP5 adoption inside PEAR,
Like, PEAR would drop support for PH
+1.
The patch is actually a one liner :)
-"var" {
+("var"|"public") {
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
35 matches
Mail list logo
