Re: [PHP-DEV] ereg deprecation?
2010/5/31 Felipe Pena > > 2010/5/31 Johannes Schlüter > > > On Mon, 2010-05-31 at 14:09 -0300, Felipe Pena wrote: > > > Hi, > > > > > > 2010/4/28 Michael Maclean > > > > > > > Hi, > > > > I think I asked this before on IRC, but I've forgotten the answer. I > > was > > > > just remembering that the ereg extension was due to be deprecated in > > PHP6 - > > > > does this still apply to trunk? > > > > > > > > > > > I think make no sense to keep it deprecated. > > > > > > Here's a patch for undeprecate ext/ereg in 5_3 and trunk: > > > http://felipe.ath.cx/diff/undeprecate-ereg.diff > > > > > > Any objection? If no, I'll commit it in soon. > > > > I still won't recommend using ereg - the missing binary-safety causes > > quite some broken checks ... is there anything that can be done which > > can't be done using pcre? If not: Less code to maintain -> less > > trouble :-) > > > > > I also won't recommend using ereg, I just thought the unique reason to > deprecate it was the unicode stuff, hence wouldn't make sense to keep it > deprecated... But as there are others motivations, I prefer leave as is too. > > -- > Regards, > Felipe Pena Undeprecating the ereg extension now will not only cause confusion, because it has been deprecated for quite a while already, but it might also become a liability if Unicode or any similar non-compatible system might ever be included in the future. PCRE simply is faster under most conditions, more consistent and since a significant part of PHP Developers will also use Javascript, likely to be more appropriate for the web. Companies and individuals have been adjusting their scripts in favor of PCRE[1][2][3], undeprecating the extension seems senseless at this point. I do think Philip Olson's proposal of adding a compile-time flag for disabling ereg altogether is a good idea, as it would be the next step in moving ereg away from PHP's core. Regards, Peter Beverloo [1] https://drupal.org/node/530940 [2] http://bugs.typo3.org/view.php?id=9994 [3] http://www.mantisbt.org/bugs/view.php?id=10974 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ereg deprecation?
2010/5/31 Johannes Schlüter > On Mon, 2010-05-31 at 14:09 -0300, Felipe Pena wrote: > > Hi, > > > > 2010/4/28 Michael Maclean > > > > > Hi, > > > I think I asked this before on IRC, but I've forgotten the answer. I > was > > > just remembering that the ereg extension was due to be deprecated in > PHP6 - > > > does this still apply to trunk? > > > > > > > > I think make no sense to keep it deprecated. > > > > Here's a patch for undeprecate ext/ereg in 5_3 and trunk: > > http://felipe.ath.cx/diff/undeprecate-ereg.diff > > > > Any objection? If no, I'll commit it in soon. > > I still won't recommend using ereg - the missing binary-safety causes > quite some broken checks ... is there anything that can be done which > can't be done using pcre? If not: Less code to maintain -> less > trouble :-) > > I also won't recommend using ereg, I just thought the unique reason to deprecate it was the unicode stuff, hence wouldn't make sense to keep it deprecated... But as there are others motivations, I prefer leave as is too. -- Regards, Felipe Pena
Re: [PHP-DEV] Type hinting
thank you, btw. I don't know how did that happen, I copypasted from my previous post, which has $var++ in it :) Tyrael On Mon, May 31, 2010 at 7:06 PM, Julien Pauli wrote: > Well at least I fixed the splweaktypehintingwithautoboxing for the function > to return ++$var instead of $var++ which couldn't make it ;-) > > Julien > > > On Mon, May 31, 2010 at 5:54 PM, Ferenc Kovacs wrote: > >> On Mon, May 31, 2010 at 2:42 PM, Lukas Kahwe Smith > >wrote: >> >> > >> > On 28.05.2010, at 11:50, Lukas Kahwe Smith wrote: >> > >> > > >> > > On 28.05.2010, at 11:22, Etienne Kneuss wrote: >> > > >> > >> so, it would be nice to update the RFC(s), so that we have a solid >> > >> ground on which we can discuss/vote. >> > > >> > > >> > > i agree. i currently see 5 fundamental different options on the table: >> > > >> > > 1) current trunk >> > > 2) current trunk but only with scalar/numeric type support >> > > 3) weak typing with current PHP conversion rules that raise an >> E_STRICT >> > on data loss >> > > 4) weak typing with new conversion rules >> > > 5) some syntax to allow both one of 1)/2) and 3)/4)/5) >> > > >> > > i can take care of 3), 4) and 5) over the weekend, though for 4b) (see >> > below) i would like to get some feedback from others >> > > >> > > other than that i agree that we have beat this horse long enough that >> we >> > can then pretty quickly move to a vote. that being said, i think we >> should >> > do the vote by allowing people to then sort the RFC's in order of >> preference >> > with the option of leaving options out that they want to veto. >> > > >> > > of course if 6) gets voted for we would then have to decide on which >> of >> > the permutations (1/3, 1/4, 1/5, 2/3, 2/4, 2/5) to go with in a second >> vote. >> > >> > >> > ok .. i adjusted the weak type hinting RFC to cover 3) and 4). >> > so i guess it would be nice if someone could create and RFC for 2) (as I >> > guess the strict typing RFC covers 1)?) and if someone believes in a >> > combined approach (Derick?) create an RFC for 5). >> > if someone wants to do an SPL based exception approach, feel free to >> create >> > a new RFC. >> > >> > >> http://wiki.php.net/rfc/splweaktypehintingwithautoboxing >> Sorry for my poor english grammar, feel free to correct/expand/challenge >> it. >> >> Tyrael >> > >
Re: [PHP-DEV] ereg deprecation?
2010/6/1 Johannes Schlüter : > On Mon, 2010-05-31 at 14:09 -0300, Felipe Pena wrote: >> I think make no sense to keep it deprecated. >> >> Here's a patch for undeprecate ext/ereg in 5_3 and trunk: >> http://felipe.ath.cx/diff/undeprecate-ereg.diff >> >> Any objection? If no, I'll commit it in soon. > > I still won't recommend using ereg - the missing binary-safety causes > quite some broken checks ... is there anything that can be done which > can't be done using pcre? If not: Less code to maintain -> less > trouble :-) I believe PCRE's generally quicker into the bargain anyway. We've already told people we're killing ereg, and there are good reasons to do so regardless of Unicode (lack of binary safety being the main one, with the needless duplication with PCRE being another). Let's keep it deprecated and kill it when it makes sense to do so (next major, or if and when Unicode comes back at some future date). Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ereg deprecation?
On 31.05.2010, at 19:23, Johannes Schlüter wrote: > On Mon, 2010-05-31 at 14:09 -0300, Felipe Pena wrote: >> Hi, >> >> 2010/4/28 Michael Maclean >> >>> Hi, >>> I think I asked this before on IRC, but I've forgotten the answer. I was >>> just remembering that the ereg extension was due to be deprecated in PHP6 - >>> does this still apply to trunk? >>> >>> >> I think make no sense to keep it deprecated. >> >> Here's a patch for undeprecate ext/ereg in 5_3 and trunk: >> http://felipe.ath.cx/diff/undeprecate-ereg.diff >> >> Any objection? If no, I'll commit it in soon. > > I still won't recommend using ereg - the missing binary-safety causes > quite some broken checks ... is there anything that can be done which > can't be done using pcre? If not: Less code to maintain -> less > trouble :-) i would still keep it deprecated simply because people should not write new code with ereg, even if we do not have to remove it because of lack of unicode support. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ereg deprecation?
hi, I don't think we should remove it. The sooner users stop to use ereg, the better. Cheers, -- Pierre On Mon, May 31, 2010 at 7:09 PM, Felipe Pena wrote: > Hi, > > 2010/4/28 Michael Maclean > >> Hi, >> I think I asked this before on IRC, but I've forgotten the answer. I was >> just remembering that the ereg extension was due to be deprecated in PHP6 - >> does this still apply to trunk? >> >> > I think make no sense to keep it deprecated. > > Here's a patch for undeprecate ext/ereg in 5_3 and trunk: > http://felipe.ath.cx/diff/undeprecate-ereg.diff > > Any objection? If no, I'll commit it in soon. > > -- > Regards, > Felipe Pena > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ereg deprecation?
On Mon, 2010-05-31 at 18:20 +0100, Mark Skilbeck wrote: > > I think make no sense to keep it deprecated. > > > > Here's a patch for undeprecate ext/ereg in 5_3 and trunk: > > http://felipe.ath.cx/diff/undeprecate-ereg.diff > > > > Any objection? If no, I'll commit it in soon. > > > > Why does it make no sense? It was clearly deprecated for a reason. The main reason was that PHP 6 was Unicode and ereg ca't be made working with Unicode. That reason is gone (for now) (but there are others, see my other mail) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ereg deprecation?
On Mon, 2010-05-31 at 14:09 -0300, Felipe Pena wrote: > Hi, > > 2010/4/28 Michael Maclean > > > Hi, > > I think I asked this before on IRC, but I've forgotten the answer. I was > > just remembering that the ereg extension was due to be deprecated in PHP6 - > > does this still apply to trunk? > > > > > I think make no sense to keep it deprecated. > > Here's a patch for undeprecate ext/ereg in 5_3 and trunk: > http://felipe.ath.cx/diff/undeprecate-ereg.diff > > Any objection? If no, I'll commit it in soon. I still won't recommend using ereg - the missing binary-safety causes quite some broken checks ... is there anything that can be done which can't be done using pcre? If not: Less code to maintain -> less trouble :-) johanns -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ereg deprecation?
On 31/05/10 18:09, Felipe Pena wrote: Hi, 2010/4/28 Michael Maclean Hi, I think I asked this before on IRC, but I've forgotten the answer. I was just remembering that the ereg extension was due to be deprecated in PHP6 - does this still apply to trunk? I think make no sense to keep it deprecated. Here's a patch for undeprecate ext/ereg in 5_3 and trunk: http://felipe.ath.cx/diff/undeprecate-ereg.diff Any objection? If no, I'll commit it in soon. Why does it make no sense? It was clearly deprecated for a reason. -- Mark Skilbeck mahcuz.com | gtk.php.net | pecl.php.net/cairo | docs.php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ereg deprecation?
Hi, 2010/4/28 Michael Maclean > Hi, > I think I asked this before on IRC, but I've forgotten the answer. I was > just remembering that the ereg extension was due to be deprecated in PHP6 - > does this still apply to trunk? > > I think make no sense to keep it deprecated. Here's a patch for undeprecate ext/ereg in 5_3 and trunk: http://felipe.ath.cx/diff/undeprecate-ereg.diff Any objection? If no, I'll commit it in soon. -- Regards, Felipe Pena
Re: [PHP-DEV] Type hinting
Well at least I fixed the splweaktypehintingwithautoboxing for the function to return ++$var instead of $var++ which couldn't make it ;-) Julien On Mon, May 31, 2010 at 5:54 PM, Ferenc Kovacs wrote: > On Mon, May 31, 2010 at 2:42 PM, Lukas Kahwe Smith >wrote: > > > > > On 28.05.2010, at 11:50, Lukas Kahwe Smith wrote: > > > > > > > > On 28.05.2010, at 11:22, Etienne Kneuss wrote: > > > > > >> so, it would be nice to update the RFC(s), so that we have a solid > > >> ground on which we can discuss/vote. > > > > > > > > > i agree. i currently see 5 fundamental different options on the table: > > > > > > 1) current trunk > > > 2) current trunk but only with scalar/numeric type support > > > 3) weak typing with current PHP conversion rules that raise an E_STRICT > > on data loss > > > 4) weak typing with new conversion rules > > > 5) some syntax to allow both one of 1)/2) and 3)/4)/5) > > > > > > i can take care of 3), 4) and 5) over the weekend, though for 4b) (see > > below) i would like to get some feedback from others > > > > > > other than that i agree that we have beat this horse long enough that > we > > can then pretty quickly move to a vote. that being said, i think we > should > > do the vote by allowing people to then sort the RFC's in order of > preference > > with the option of leaving options out that they want to veto. > > > > > > of course if 6) gets voted for we would then have to decide on which of > > the permutations (1/3, 1/4, 1/5, 2/3, 2/4, 2/5) to go with in a second > vote. > > > > > > ok .. i adjusted the weak type hinting RFC to cover 3) and 4). > > so i guess it would be nice if someone could create and RFC for 2) (as I > > guess the strict typing RFC covers 1)?) and if someone believes in a > > combined approach (Derick?) create an RFC for 5). > > if someone wants to do an SPL based exception approach, feel free to > create > > a new RFC. > > > > > http://wiki.php.net/rfc/splweaktypehintingwithautoboxing > Sorry for my poor english grammar, feel free to correct/expand/challenge > it. > > Tyrael >
Re: [PHP-DEV] Type hinting
On Mon, May 31, 2010 at 2:42 PM, Lukas Kahwe Smith wrote: > > On 28.05.2010, at 11:50, Lukas Kahwe Smith wrote: > > > > > On 28.05.2010, at 11:22, Etienne Kneuss wrote: > > > >> so, it would be nice to update the RFC(s), so that we have a solid > >> ground on which we can discuss/vote. > > > > > > i agree. i currently see 5 fundamental different options on the table: > > > > 1) current trunk > > 2) current trunk but only with scalar/numeric type support > > 3) weak typing with current PHP conversion rules that raise an E_STRICT > on data loss > > 4) weak typing with new conversion rules > > 5) some syntax to allow both one of 1)/2) and 3)/4)/5) > > > > i can take care of 3), 4) and 5) over the weekend, though for 4b) (see > below) i would like to get some feedback from others > > > > other than that i agree that we have beat this horse long enough that we > can then pretty quickly move to a vote. that being said, i think we should > do the vote by allowing people to then sort the RFC's in order of preference > with the option of leaving options out that they want to veto. > > > > of course if 6) gets voted for we would then have to decide on which of > the permutations (1/3, 1/4, 1/5, 2/3, 2/4, 2/5) to go with in a second vote. > > > ok .. i adjusted the weak type hinting RFC to cover 3) and 4). > so i guess it would be nice if someone could create and RFC for 2) (as I > guess the strict typing RFC covers 1)?) and if someone believes in a > combined approach (Derick?) create an RFC for 5). > if someone wants to do an SPL based exception approach, feel free to create > a new RFC. > > http://wiki.php.net/rfc/splweaktypehintingwithautoboxing Sorry for my poor english grammar, feel free to correct/expand/challenge it. Tyrael
Re: [PHP-DEV] Type hinting
On 28.05.2010, at 11:50, Lukas Kahwe Smith wrote: > > On 28.05.2010, at 11:22, Etienne Kneuss wrote: > >> so, it would be nice to update the RFC(s), so that we have a solid >> ground on which we can discuss/vote. > > > i agree. i currently see 5 fundamental different options on the table: > > 1) current trunk > 2) current trunk but only with scalar/numeric type support > 3) weak typing with current PHP conversion rules that raise an E_STRICT on > data loss > 4) weak typing with new conversion rules > 5) some syntax to allow both one of 1)/2) and 3)/4)/5) > > i can take care of 3), 4) and 5) over the weekend, though for 4b) (see below) > i would like to get some feedback from others > > other than that i agree that we have beat this horse long enough that we can > then pretty quickly move to a vote. that being said, i think we should do the > vote by allowing people to then sort the RFC's in order of preference with > the option of leaving options out that they want to veto. > > of course if 6) gets voted for we would then have to decide on which of the > permutations (1/3, 1/4, 1/5, 2/3, 2/4, 2/5) to go with in a second vote. ok .. i adjusted the weak type hinting RFC to cover 3) and 4). so i guess it would be nice if someone could create and RFC for 2) (as I guess the strict typing RFC covers 1)?) and if someone believes in a combined approach (Derick?) create an RFC for 5). if someone wants to do an SPL based exception approach, feel free to create a new RFC. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
I remember Marcus worked on something like that some time ago. Might still
be into SVN or somewhere I think.
Julien
On Sat, May 29, 2010 at 9:03 PM, Ferenc Kovacs wrote:
> On Sat, May 29, 2010 at 7:34 PM, Zeev Suraski wrote:
>
> > At 20:28 29/05/2010, Chris Stockton wrote:
> >
> > My biggest issue as a user is the fatal errors. Why are we blowing up on
> >> something that should throw some kind of useful argument exception? I
> end up
> >> in my applications using instanceof everywhere because their is
> important
> >> cleanup to be done before the end of the request. For example I can't
> afford
> >> for php to just blow up in our account setup script, we are reaching out
> to
> >> multiple non-transactional external resources. Some of our long running
> >> command line processes have the same issue. I am all for type hinting
> but
> >> the fatal errors or "catchabale" fatal errors are just silly. Exceptions
> >> make so much more sense to me.
> >>
> >
> > IMHO we shouldn't be getting to any kind of fatal error/exception
> > situation, which is why I like the idea of auto-conversion plus E_STRICT
> in
> > the 'weird conversion' scenarios (the API function shouldn't care - it
> got
> > what it asked for; The caller would get notified that he passed
> something
> > that probably doesn't make sense).
> > But as to why errors and not exceptions - we have a guideline that
> language
> > constructs don't through exceptions. It's up to users whether they want
> to
> > use exceptions or not.
> >
> >
> > Zeev
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> I'm thinking about the type hinting in php for a while, and there is my 2
> cent about this.
>
> As an API developer, I need a way, to easily force my input into a proper
> type, with ease, without dataloss, and without code duplication.
> As an API consumer, I don't want to bother much about my API calls, as long
> as my passed arguments are in the accepted form(I don't want to
> convert '123' into 123), and I don't want to create yet another custom
> error
> handler, to fetch the potentially triggered errors, and I cannot allow,
> that
> one unhandled catcable fatal error ruin my application.
>
> So basically I need type jugling(weak type hinting) + exceptions instead of
> catchable errors.
> But I know that the core should't throw exceptions, so we can't go to that
> direction.
>
> What if we introduce a new spl interface, which propose auto boxing for the
> scalar types + exceptions for the type missmatch.
> I mean, if you call that class with scalar arguments, the scalar values
> will
> be converted to the matching spl class instance.
> This way, you could hint your types for the interface without forcing the
> api consumer to bother to convert '123' to 123 before passing it to the
> method.
> But if the consumer passes '123abc' when I'm hinting SplInt, then it will
> throw an InvalidArgumentException or such.
>
> So for example:
>
> class foo implements WeakTypeHinting{
> public function bar(SplInt $baz){
> return $baz++;
> }
> }
>
> $foo = new foo;
> echo $foo->bar(1);
> // 2
> echo $foo->bar('2');
> // 3
> echo $foo->bar('3a')
> // InvalidArgumentException
>
> Feel free to discuss.
>
> Tyrael
>
Re: [PHP-DEV] ChangeLog
Zitat von Pierre Joye : 2010/5/29 Johannes Schlüter : Hey, On Fri, 2010-05-28 at 23:50 +0200, Pierre Joye wrote: I'd to add that unless we add everything in the NEWS file, the ChangeLog remains the only way to have a list of all changes (without doing manually). Having the file is absolutely fine with me, while I can fulfill my needs with svn annotate and svn log. But if we ship it, it should be correct and at least since 5.2.0 we ship a wrong (not updated) file. And that I consider bad. So I ask somebody to either remove it or make sure it's updated (automatically or by adding instructions to README.RELEASE_PROCESS) in all places. Maybe simply do it at release time? Having the changelog updated automatically used to be a really useful thing, because there also existed a mailing list that sent daily (or weekly?) diffs to the changelog file. This way you could easily follow development of PHP without having to subscribe to the commits mailing list. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: NEW-OUTPUT-API patch - update
On 05/28/2010 04:15 PM, Felipe Pena wrote: 2010/5/28 Michael Wallner Yeah! Thanks a lot. But there are so many changes in this patch which have absolutely nothing to do with the topic, read: stop your editor from doing unintentional white space clean up :) Could you produce a ws-agnostic patch? That would be awesome. http://felipe.ath.cx/diff/mike-new-output-api-clean.diff :-) Thank you! I'll handle the rest. I think I could remove the "zvalism" again as there's no need for it, as it actually has been introduced due to unicode. Cheers, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
