Ilia Alshanetsky wrote:
> Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
+0
> Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;
-1
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E
On 17.05.2006 03:26, Ilia Alshanetsky wrote:
There are 2 PHP 5.2 changes there has been a lot of back and forth
flaming going around and we need to finally come to a decision about.
The two topics are:
Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
E_RECOVERABLE should stay.
E_STR
Ilia Alshanetsky wrote:
Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
I do not like the idea of changing the constants in a minor release. I
know "ALL" implies includes everything but I prefer to keep E_ALL like
it is and add an E_PEDANTIC (and default to that in the sample ini fi
Ilia Alshanetsky wrote:
There are 2 PHP 5.2 changes there has been a lot of back and forth
flaming going around and we need to finally come to a decision about.
The two topics are:
Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
I don't like E_ALL & ~E_NOTICE suddenly starting to th
On 17.5.2006 1:26 Uhr, Ilia Alshanetsky wrote:
> There are 2 PHP 5.2 changes there has been a lot of back and forth
> flaming going around and we need to finally come to a decision about.
>
> The two topics are:
>
> Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
-1, especially for in
Hello Marcus,
I've put together a simple test framework and a 18 test cases to
start with. It's a stand-alone system that should work correctly
on PHP 5 installs. Both CLI mode and Web Server mode work fine.
NOTE: The tests I wrote are only testing standard functionality. We
need to a
Marcus Boerger wrote:
Hello folks,
i see at least two bigger comlain threads going on. But i don't see
anybody writing tests or offering additions to the upgrade info files
be it for version 5.2 or 6.0. So is comlaining so easy and writing php
so hard?
As a reminder on how to write tests:
Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
+1
Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;
-1
--
Brian Moon
-
http://dealnews.com/
Its good to be cheap =)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: h
On Tue, 16 May 2006, Ilia Alshanetsky wrote:
> There are 2 PHP 5.2 changes there has been a lot of back and forth flaming
> going around and we need to finally come to a decision about.
>
> The two topics are:
>
> Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
E_RECOVERABLE_ERROR shou
On 5/16/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
-1
Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;
-1.
--Wez.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.p
-1 on both here, E_STRICT can wait and dynamic static variables are
pretty pointless, the workaround is clearer than the kludge..
StaticClass::$options['somekey'] = 'value';
Regards
Alan
Ilia Alshanetsky wrote:
There are 2 PHP 5.2 changes there has been a lot of back and forth
flaming going
On 16-May-06, at 7:50 PM, Marcus Boerger wrote:
Hello Ilia,
Wednesday, May 17, 2006, 1:26:37 AM, you wrote:
Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
+1
While doing all the stuff we wanted for 5.2 we also added
E_RECOVERABLE_ERROR. This includes stuff that was E_ERROR before
Hello Ilia,
second try of second part this time using static. I guess i need sleep.
Wednesday, May 17, 2006, 1:26:37 AM, you wrote:
> Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;
-1
If we go that road i suggest we simply drop support for STATIC. Fixing
the issues
Hello Ilia,
Wednesday, May 17, 2006, 1:26:37 AM, you wrote:
> Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
+1
I gave my best on this. But be sure. I'll just ignore any whining on
any change that has a E_STRICT in older versions when doing changes
in any version after 5.2.
Also befor
Hello D.,
Wednesday, May 17, 2006, 1:28:26 AM, you wrote:
> Jason Garber wrote:
>> CS> Does anyone apart from me wonder why we need to bloat the language for
>> CS> an obscure feature like this? Please take a step back, take a deep
>> CS> breath, count to 10 and that's *really* what the PHP comm
On Tue, 16 May 2006 19:26:37 -0400
[EMAIL PROTECTED] (Ilia Alshanetsky) wrote:
> There are 2 PHP 5.2 changes there has been a lot of back and forth
> flaming going around and we need to finally come to a decision about.
>
> The two topics are:
>
> Inclusion of E_STRICT and E_RECOVERABLE_ERROR
So, would that make it - non cents?
...sorry, couldn't resist
-D
On May 16, 2006, at 5:26 PM, Ilia Alshanetsky wrote:
So please throw in your +1/-1
Darrell Brogdon
[EMAIL PROTECTED]
http://darrell.brogdon.net
http://phpflashcards.com
Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
-1
Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;
+1
Edin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Jason Garber wrote:
CS> Does anyone apart from me wonder why we need to bloat the language for
CS> an obscure feature like this? Please take a step back, take a deep
CS> breath, count to 10 and that's *really* what the PHP community has been
CS> waiting for.
Please consider that not everyone d
There are 2 PHP 5.2 changes there has been a lot of back and forth
flaming going around and we need to finally come to a decision about.
The two topics are:
Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;
So ple
> On May 13, 2006, at 7:18 PM, Marcus Boerger wrote:
>
> > hehe, maybe confused with delphi or borlands c++
> additons? Speaking
> > of which before we add 'readonly' we should go for full property
> > support but on the other hand that might be a little bit too much
> > until php is used
Hello Christian,
CS> Does anyone apart from me wonder why we need to bloat the language for
CS> an obscure feature like this? Please take a step back, take a deep
CS> breath, count to 10 and that's *really* what the PHP community has been
CS> waiting for.
Please consider that not everyone does t
Marcus Boerger wrote:
i changed from readonly to readable, which means the new keyword makes it
public for any read access, that is:
So much for "readable" being obvious (i.e. you have to explain it).
private readable $abc;
- class itself can read and write
- public for everybody w
Hello Andi,
Tuesday, May 16, 2006, 11:09:51 PM, you wrote:
> Hi Marcus,
> I don't see why everything is always personal for you.
Na. Don't get me wrong here. I am just trying to express that what we did
in the past didn't really work out. The conservative behavior of adding
new features late if
Hello Jason,
i changed from readonly to readable, which means the new keyword makes it
public for any read access, that is:
private readable $abc;
- class itself can read and write
- public for everybody when reading, inside & outside of the class
protected readable $abc;
- clas
Hello folks,
i see at least two bigger comlain threads going on. But i don't see
anybody writing tests or offering additions to the upgrade info files
be it for version 5.2 or 6.0. So is comlaining so easy and writing php
so hard?
Best regards,
Marcus
p.s.: I of course see a bunch of people w
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Richard Lynch wrote:
> On Tue, May 16, 2006 2:12 am, Jasper Bryant-Greene wrote:
>> I like this idea. I can volunteer to do reasonably thorough testing
>> (both a 'make test' and real-world app testing) of 5.x releases on a
>> very large OO applic
Hello Marcus,
Is this correct?
private readable $abc;
- doesn't make sense.
protected readable $abc;
- sub-class can read, not write
- not visible outside class
public readable $abc;
- sub-class can read, and write
- outside class can read, not write
If not, please cl
Hello Jason,
write testcase, write in a way that they capture any usage you can
think of. Parameter parsing, reference handling returning, inheritance,
trying to circumvent the whole stuff, checking all error messages are
in place, overloading internal objects that have special handlers just
to
Yeah you can take a look at internal functions/classes that operate
on objects and see whether the readonly semantics might need to work
in some of those cases.
Thanks for the offer!
At 02:59 PM 5/16/2006, Jason Garber wrote:
Hello Andi,
Your request for edge condition research is an excel
Hello Andi,
Your request for edge condition research is an excellent one. We've
just been through a hellish couple weeks of QA failures (at my
company) which just *underscore* your point. The last thing any of
us needs is a broken PHP.
That being said, is there anything I can do to he
Hello Andi,
nothing else needs to be fixed. The patch considers a reference as a write
operation as well as anything else that doesn't identify itself as a read
operation. And the enforcement itself just means that whatever you define
besides readable is being ignored for read operations.
best
Where would readable be enforced? Would it try and prevent getting
references to it? Are there any internal functions/classes which need
fixing to honor readable?
I think these answers would really be helpful.
Thanks.
Andi
At 02:37 PM 5/16/2006, Marcus Boerger wrote:
Hello Andi,
that is
Hello Zeev,
Tuesday, May 16, 2006, 11:08:57 PM, you wrote:
>> Anyway it adds complexity to what you
>>have to learn about PHP. In fact seeing two visibility keywords separated
>>by a colon should be easy enough to understand for everybody.
> I'll be blunt as it's late here, but that's just
Hello Andi,
that is why most here already switched to "public readable".
best regards
marcus
Tuesday, May 16, 2006, 11:31:14 PM, you wrote:
> I can't quite explain it but for me the ability to work-around
> private with methods which are able to access the private variable,
> is different t
I can't quite explain it but for me the ability to work-around
private with methods which are able to access the private variable,
is different than marking a property as read-only but it not being
read-only in all semantics. Probably because private variables do
often have getters and setters,
Hi Marcus,
I don't see why everything is always personal for you. As I mentioned
numerous times in the past, having an in-depth discussion about
features, both their implementation, affect on language semantics,
and relevance to PHP is very beneficial for all. All I meant was that
the impleme
At 21:33 16/05/2006, Marcus Boerger wrote:
Hello Andi, hello List,
this patch does not introduce a new keywors and thus comes with a whole
set of problems canceled out already.
I think that it's absolutely horrible syntax wise :) private:public $foo?
Anyway it adds complexity to what you
Phil Driscoll wrote:
Please add and/subtract to/from the above lists.
MediaWiki
Mambo/Joombla/Nuke
Those are the big in their space. We use MediaWiki daily in our company.
--
Brian Moon
-
http://dealnews.com/
Its good to be cheap =)
--
PHP Internals - PHP Runtime Development Ma
On Tue, May 16, 2006 8:04 am, Sebastian Bergmann wrote:
> Ilia Alshanetsky wrote:
>> For every RC we already send an e-mail to about 12 projects asking
>> them
>> to test their code against the release and let us know of any issues
>> that come up.
>
> Sadly, this does not seem to work. Maybe beca
Hello Andi,
however the past has tought of something. Nobody will test a patch.
That said there won't be any feedback until it gets into at least head
and people feel confident they should experiment with it. As it stands
now you could just take it as a decision against it and be done.
best reg
On Tuesday 16 May 2006 21:35, Richard Lynch wrote:
> Would it be worth having a checklist of "must-have" software?
>
> It's easy to see something big getting missed just because "Joe" is on
> vacation or too busy to test, and everybody knows "Joe" is gonna test
> it...
Yes, so we need a list plus
On Tue, May 16, 2006 3:44 am, Ron Korving wrote:
> Like you, I don't see why a 'readable' keyword should make things any
> more
> complicated for beginners, because indeed, it is optional and
> beginners will
> simply not use it. To me, this only shows the strength of PHP:
> suitable for
> beginner
On Tue, May 16, 2006 2:12 am, Jasper Bryant-Greene wrote:
> I like this idea. I can volunteer to do reasonably thorough testing
> (both a 'make test' and real-world app testing) of 5.x releases on a
> very large OO application running on Linux / Apache 2.2. It's not an
> open-source app, but that d
I suggest to wait for a response about the edge cases question I sent
out (i.e. returning a writable reference of this readonly property).
I for one haven't quite understood what the semantics will be in all
the edge case situations. Although I think the concept is interesting
(and somewhat ben
On Tue, May 16, 2006 2:07 am, Phil Driscoll wrote:
> On Tuesday 16 May 2006 01:04, Lukas Smith wrote:
>> That being said .. if there are any additions people have to give
>> better
>> guidelines for RM's please drop a comment at the following address:
>> http://oss.backendmedia.com/ReleaseChecklist
Marcus Boerger wrote:
btw, i wonder where the people are that usually complain about my patches?
Is this finally something most people like?
Maybe you built a nuclear power plant.
Dante
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.
Hello Andi, hello List,
this patch does not introduce a new keywors and thus comes with a whole
set of problems canceled out already. Anyway it adds complexity to what you
have to learn about PHP. In fact seeing two visibility keywords separated
by a colon should be easy enough to understand for
I tested PHP with Caraveo's isapi_fcgi.dll before 5.1.4 release too.
And it worked.
I'll try to reproduce the bug, but may be message "HTTP/1.1 503 Server too
busy" is not related to PHP FastCGI.
Thanks. Dmitry.
> -Original Message-
> From: Wez Furlong [mailto:[EMAIL PROTECTED]
> Sent: T
http://bugs.php.net/bug.php?id=37448 is their bug report.
It sounds like fastcgi works with the zend implementation, but not others.
--Wez.
On 5/15/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
Interesting, what os is this one and can they provide more info in
regard to what "does not work" ?
Ilia Alshanetsky wrote:
For every RC we already send an e-mail to about 12 projects asking them
to test their code against the release and let us know of any issues
that come up. If you want to be part of this group ask Lukas to add you
to the wiki page that can be found here: http://oss.backen
Sebastian Bergmann wrote:
Stefan Walk wrote:
I'm against visible private variables. If they are visible, they are
part of the interface of the class, which means changing the
implementation means a BC break.
This is a valid point against readonly, indeed.
no, it is a valid point against im
Stefan Walk wrote:
> I'm against visible private variables. If they are visible, they are
> part of the interface of the class, which means changing the
> implementation means a BC break.
This is a valid point against readonly, indeed.
--
Sebastian Bergmann http://www.sebas
That's a good point. It was just an idea really, hoping to provide an easy
way out for the whole discussion ;)
Ron
""Stefan Walk"" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
On 5/16/06, Ron Korving <[EMAIL PROTECTED]> wrote:
>
> class Foo
> {
> private $bar = 5;
> }
>
> $
On 5/16/06, Ron Korving <[EMAIL PROTECTED]> wrote:
bar; // prints 5
$foo->bar = 4; // error
?>
I'm against visible private variables. If they are visible, they are
part of the interface of the class, which means changing the
implementation means a BC break. If this functionality is going in
Ilia Alshanetsky wrote:
> For every RC we already send an e-mail to about 12 projects asking them
> to test their code against the release and let us know of any issues
> that come up.
Sadly, this does not seem to work. Maybe because nobody from the
projects feels responsible?
--
Sebastian Ber
On Tuesday 16 May 2006 13:51, Ilia Alshanetsky wrote:
> For every RC we already send an e-mail to about 12 projects asking
> them to test their code against the release and let us know of any
> issues that come up. If you want to be part of this group ask Lukas
> to add you to the wiki page that ca
For every RC we already send an e-mail to about 12 projects asking
them to test their code against the release and let us know of any
issues that come up. If you want to be part of this group ask Lukas
to add you to the wiki page that can be found here: http://
oss.backendmedia.com/PhP5yz
"Zeev Suraski" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> ...
> Regarding whether it's an access level or a modifier, I think that an
> access level is better since you don't have to explain a matrix of 6
> different behaviors (including one that doesn't make sense, but stil
Ron,
As I've said numerous times in the past, it's not about what
beginners use or not, it's about whether it's in the language or not.
Additional keywords and structures make the language more
complicated. It's an axiom. Look at PHP 5 books vs. PHP 4 books,
including books for beginners.
Ron Korving wrote:
Like you, I don't see why a 'readable' keyword should make things any more
complicated for beginners, because indeed, it is optional and beginners will
simply not use it. To me, this only shows the strength of PHP: suitable for
beginners and suitable for the enterprise.
Lea
Nothing serious was changed after 5.1.4 releas and 5.2 before May 15.
But changes in 5.2 don't fix any bugs.
The only fix that was done - is fix for bug #37313, but it just removes
compiler warning.
Thanks. Dmitry.
> -Original Message-
> From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] O
This is absolutely true. Besides, adding a new access level automatically
implies that you'll probably never be able to extend it to protected as
well, because you'd need yet another access level and I really doubt people
are going to want to do that. But at that point, it would be too late to
Hello Phil,
Tuesday, May 16, 2006, 9:07:13 AM, you wrote:
> On Tuesday 16 May 2006 01:04, Lukas Smith wrote:
>> That being said .. if there are any additions people have to give better
>> guidelines for RM's please drop a comment at the following address:
>> http://oss.backendmedia.com/ReleaseChe
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Phil Driscoll wrote:
> On Tuesday 16 May 2006 01:04, Lukas Smith wrote:
>> That being said .. if there are any additions people have to give better
>> guidelines for RM's please drop a comment at the following address:
>> http://oss.backendmedia.c
On Tuesday 16 May 2006 01:04, Lukas Smith wrote:
> That being said .. if there are any additions people have to give better
> guidelines for RM's please drop a comment at the following address:
> http://oss.backendmedia.com/ReleaseChecklist
I've just added the following comment, which addresses pa
66 matches
Mail list logo
