Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
On Sun, Oct 12, 2014 at 12:36 PM, Zeev Suraski wrote: > > For the record, I don't feel strongly about # comments, but I do think that > we should have good reasons to actually *remove* features that are better > than "this is how it's done". Valid reasons can be performance penalties of > keeping the feature, security issues, or potential significant reduction in > codebase complexity. I'm not sure whether # comments fall into any of these > buckets, but sounds like they don't. > > Each and every feature we break makes it a bit more difficult > to upgrade. The more difficult we make it - the more people are likely to > stick with old insecure versions, or visit alternative > options I have to agree with Zeev here, with one additional note. We have chosen to deprecate features, including ext/mysql. If we now decide not to remove some of them for 7, we may just remove the deprecation flag as we are going to support them for the next decade as well, whether we like it or not. >From the distros/pecl vs core, it is in my humble opinion, a non issue. Most of the major applications support alternative drivers now, including the most conservative ones like Wordpress (it is not badly meant, only a a statement about the situation). Distros tend to enable by default what the core provides or enables by default. PHP7 will be no different. Keeping it forever won't help. Removing it may not help as much as we wish but it will be a clear, loud and unambiguous signal, which is a good step forward. I also agree to have more options to vote on. Mass voting may hide something most of us won't notice. I also like to discuss what we do for the deprecated features we won't remove. Keeping the deprecated flags for the sake of keeping it sounds not so good. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API
On Mon, 2014-10-13 at 02:45 +0200, Marco Pivetta wrote: > The point is removing more API from core and moving it to userland. > API implemented in core needs to be maintained by core devs, and is > non-transparent to consumers (reflection/debugging/etc). > In general, I've always been against any non-language feature that isn't > implemented with the language itself, but it's my point of view: as a > simple rule of thumb (my rule, many would just say I'm crazy), if it can be > implemented in PHP, then don't add it to core or extensions. For *adding* features that is a good rule. For removing not. Even less for a feature with more than a million hits on GitHub ... https://github.com/search?l=php&q=func_get_args&type=Code&utf8=%E2%9C%93 (while that metric is bad - too many duplicates due to forks and from phpt test suite, but still a notable number) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API
On 12 October 2014 00:47, Andrea Faulds wrote: > > On 11 Oct 2014, at 23:42, Rowan Collins wrote: > > > func_get_args() and func_num_args(), OTOH, existed solely to support > variadics, and anything taking advantage of them being functions rather > than a language structure would have to be quite exotic and arcane, so in > principle they could, eventually, be removed, but I agree with others that > it's far too soon to remove a feature which has been around since 4.0 just > becuase 5.6 includes a better alternative. > > They have some (admittedly limited) use beyond variadics. If you make a > function and later make it redirect to another, you can preserve your > typehints by using func_get_args() rather than using the … syntax. > Can anyone come up with those use-cases? If there is something that `func_get_args()` can do and that can't be done with the code examples that I've pasted before, then I'm missing some bits of information that may make the entire proposal moot. > > If they're included in the core distribution, then why make them > optional at all? If it's just a question of how the functions behave, then > surely an included (and C-level) implementation should be sought which has > the better behaviour? > > This matches my own thoughts. There is nothing wrong with these functions. > There are just some issues with their implementation. We do not need to get > rid of the functions, that would be an absurd overreaction. We should just > fix the implementations. The point is removing more API from core and moving it to userland. API implemented in core needs to be maintained by core devs, and is non-transparent to consumers (reflection/debugging/etc). In general, I've always been against any non-language feature that isn't implemented with the language itself, but it's my point of view: as a simple rule of thumb (my rule, many would just say I'm crazy), if it can be implemented in PHP, then don't add it to core or extensions. I would suggest the same deprecation approach for many `array_*` functions, but I assume that I'd only start a giant shitstorm (pardon the wording, but that's the most precise term for that) about performance. Anyway, it's clear that this proposal has short legs, and won't get anywhere in a vote. Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
On 12/10/2014 11:11, Nikita Popov wrote: For example, things like this: > > # style comments in ini files (since PHP 5.3) > >I don't think we should remove at all (or why is this even deprecated?! > Because ini files use ; for comments and not #. I was curious enough about this to dig into source control and do some sleuthing, and it looks like what actually led to this situation was: - Between 5.2 and 5.3 (late 2007 and early 2008), the ini parsing code saw a lot of heavy modifications [1], including a patch adding many new syntax features, and a subsequent rewrite from flex to re2c. - This, inevitably, led to a bunch of regressions. As later pointed out, the accepted format wasn't really documented in the first place. [2] - One of those bugs had to do with the parsing of # characters. [3] - The behaviour of # as comments in earlier versions seems to have been a side-effect of something else, rather than a deliberate feature. In fact, it was possible to have a key starting with #, but a line starting # that had no = was silently discarded. [4] - As a result, # was added back as an explicit comment character, but with a deprecation notice. [5] My guess is that the reasoning was that semicolon was always the "correct" comment character, so people should be encouraged to use it. Whether "deprecated" is the right word for that, I'm not sure. [1] http://lxr.php.net/history/PHP_5_3/Zend/zend_ini_scanner.l [2] https://bugs.php.net/bug.php?id=47703 [3] https://bugs.php.net/bug.php?id=44575 [4] http://3v4l.org/AoI5H [5] http://lxr.php.net/diff/PHP_5_3/Zend/zend_ini_scanner.l?r2=%2FPHP_5_3%2FZend%2Fzend_ini_scanner.l%40b3d0514b6f87af37a7750a0f4c95e4a12a8f7009&r1=%2FPHP_5_3%2FZend%2Fzend_ini_scanner.l%40193dd31a22a52cfdbd30135b1025ca774d1e98b4 -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
Hi Andrea, > Allowing # for comments stops you from using # in string property values. > > Though I'm not sure why you'd need to. That will be the case for any character to use for comments. Uses ; for comments will stop you from using it in values. Regards. -- Yannick K. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
On 12 Oct 2014, at 11:36, Zeev Suraski wrote: > For the record, I don't feel strongly about # comments, but I do think that > we should have good reasons to actually *remove* features that are better > than "this is how it's done". Valid reasons can be performance penalties of > keeping the feature, security issues, or potential significant reduction in > codebase complexity. I'm not sure whether # comments fall into any of these > buckets, but sounds like they don’t. Allowing # for comments stops you from using # in string property values. Though I’m not sure why you’d need to. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
> -Original Message- > From: Nikita Popov [mailto:nikita@gmail.com] > Sent: Sunday, October 12, 2014 1:11 PM > To: Derick Rethans > Cc: PHP internals > Subject: Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7 > > On Sun, Oct 12, 2014 at 9:56 AM, Derick Rethans wrote: > > > On Sat, 11 Oct 2014, Nikita Popov wrote: > > > > > Hi internals! > > > > > > We currently have a number of deprecated features, which we likely > > > want > > to > > > remove in PHP 7. I've created a tracking RFC listing deprecated > > > functionality (if I missed something, please tell): > > > > > > https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 > > > > > > I expect many of these are no-brainers (like assigning new > > > by-reference), but other items like removal of ext/mysql may need > > > additional consideration. > > > > > > Unless there are items that are particularly contested, I'd like to > > handle > > > the bulk of these in a single vote and only have separate votes for > > > ext/ereg and ext/mysql, as these are arguably more intrusive. > > > > I think there should be a little bit more voting "options" - or rather > > categories. > > > > For example, things like this: > > > > # style comments in ini files (since PHP 5.3) > > > > I don't think we should remove at all (or why is this even deprecated?! > > > > Because ini files use ; for comments and not #. For the record, I don't feel strongly about # comments, but I do think that we should have good reasons to actually *remove* features that are better than "this is how it's done". Valid reasons can be performance penalties of keeping the feature, security issues, or potential significant reduction in codebase complexity. I'm not sure whether # comments fall into any of these buckets, but sounds like they don't. Each and every feature we break makes it a bit more difficult to upgrade. The more difficult we make it - the more people are likely to stick with old insecure versions, or visit alternative options Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
I think there should be a little bit more voting "options" - or rather categories. For example, things like this: # style comments in ini files (since PHP 5.3) I don't think we should remove at all (or why is this even deprecated?! Because ini files use ; for comments and not #. Nikita And once again it's one of the simplest things to fix. Single find&replace should do the trick in most cases. Thanks, Maciej. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
On Sun, Oct 12, 2014 at 9:56 AM, Derick Rethans wrote: > On Sat, 11 Oct 2014, Nikita Popov wrote: > > > Hi internals! > > > > We currently have a number of deprecated features, which we likely want > to > > remove in PHP 7. I've created a tracking RFC listing deprecated > > functionality (if I missed something, please tell): > > > > https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 > > > > I expect many of these are no-brainers (like assigning new > > by-reference), but other items like removal of ext/mysql may need > > additional consideration. > > > > Unless there are items that are particularly contested, I'd like to > handle > > the bulk of these in a single vote and only have separate votes for > > ext/ereg and ext/mysql, as these are arguably more intrusive. > > I think there should be a little bit more voting "options" - or rather > categories. > > For example, things like this: > > # style comments in ini files (since PHP 5.3) > > I don't think we should remove at all (or why is this even deprecated?! > Because ini files use ; for comments and not #. Nikita
Re: [PHP-DEV] disallow non-static method calls with self/static in PHP 7
On Sun, Oct 12, 2014 at 10:37 AM, Robert Stoll wrote:
> Hey,
>
>
>
> I just stumbled over a method call of a non-static method with self and
> was asking myself again, why does PHP support
> this behaviour. An example to outline what I am writing of:
>
>
>
> class A{
>
> function foo(){
>
> self::bar();
>
> }
>
> function bar(){}
>
> }
>
>
>
> IMO it should not be allowed to call non-static methods with self or
> static. Sure, it is just a small detail but for
> someone who starts learning PHP it is an unnecessary supplement.
>
> Maybe it is too drastic to disallow it in PHP 7 but yeah. I would like to
> know what you think about it and if someone
> has a good reason why it is allowed nowadays then please help me out.
>
There's a common misconception that ::foo() denotes a static method call in
PHP. What it actually does is a *scoped* call (which is why :: is called
the "scope resolution operator" and not the "static access operator").
What :: essentially does is give you the ability to call the implementation
of a method in a particular class. A common application is the use of
parent::foo() which will not call your implementation of foo(), but the one
found in the parent class. Similarly you can use A::foo() to target a
particular class that is even further up in the inheritance hierarchy
(like, the grandparent-class). You can also call call a class that is
completely outside your inheritance hierarchy, but that's deprecated since
PHP 5.6 and will hopefully be removed in PHP 7.
Nikita
AW: [PHP-DEV] disallow non-static method calls with self/static in PHP 7
> In your given example, $this is defined when A::bar() is called; > interestingly, when this class is extended it will still only call > A::bar() as opposed to calling $this->bar(). Whether this is useful behaviour > is irrelevant :) > Right, I completely forgot that. So calling it with self instead of $this actually could make sense. Cheers :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] disallow non-static method calls with self/static in PHP 7
On 12 Oct 2014, at 16:37, Robert Stoll wrote:
> Hey,
>
>
>
> I just stumbled over a method call of a non-static method with self and was
> asking myself again, why does PHP support
> this behaviour. An example to outline what I am writing of:
>
>
>
> class A{
>
> function foo(){
>
>self::bar();
>
> }
>
> function bar(){}
>
> }
>
>
>
> IMO it should not be allowed to call non-static methods with self or static.
> Sure, it is just a small detail but for
> someone who starts learning PHP it is an unnecessary supplement.
The use of self::, static:: (or parent:: for that matter) itself doesn’t make a
method call static; it’s the declaration or caller context that makes it behave
statically, i.e. $this can’t be used.
In your given example, $this is defined when A::bar() is called; interestingly,
when this class is extended it will still only call A::bar() as opposed to
calling $this->bar(). Whether this is useful behaviour is irrelevant :)
The use of static::bar() is kind of pointless, because AFAICT there’s no
difference between that and $this->bar() in this particular example.
>
> Maybe it is too drastic to disallow it in PHP 7 but yeah. I would like to
> know what you think about it and if someone
> has a good reason why it is allowed nowadays then please help me out.
>
>
>
> Cheers,
>
> Robert
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] disallow non-static method calls with self/static in PHP 7
Hey,
I just stumbled over a method call of a non-static method with self and was
asking myself again, why does PHP support
this behaviour. An example to outline what I am writing of:
class A{
function foo(){
self::bar();
}
function bar(){}
}
IMO it should not be allowed to call non-static methods with self or static.
Sure, it is just a small detail but for
someone who starts learning PHP it is an unnecessary supplement.
Maybe it is too drastic to disallow it in PHP 7 but yeah. I would like to know
what you think about it and if someone
has a good reason why it is allowed nowadays then please help me out.
Cheers,
Robert
Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
On Oct 12, 2014 12:54 AM, "Derick Rethans" wrote: > > On Sat, 11 Oct 2014, Kris Craig wrote: > > > On Oct 11, 2014 1:52 PM, "Nikita Popov" wrote: > > > > > > We currently have a number of deprecated features, which we likely > > > want to remove in PHP 7. I've created a tracking RFC listing > > > deprecated functionality (if I missed something, please tell): > > > > > > https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 > > > > > > I expect many of these are no-brainers (like assigning new > > > by-reference), but other items like removal of ext/mysql may need > > > additional consideration. > > > > > > Unless there are items that are particularly contested, I'd like to > > > handle the bulk of these in a single vote and only have separate > > > votes for ext/ereg and ext/mysql, as these are arguably more > > > intrusive. > > > > +1 on all of that. > > > > As far as ext/mysql is concerned, I would eagerly vote in favor of removing > > it. It performs poorly, is procedural, less secure, doesn't support > > "is procedural" is however, never a reason to remove something. As most > of PHP's function library, is procedural and works just fine. Fair point. I agree that alone wouldn't be grounds to remove it. I was just citing that as one of many deficiencies compared to more current extensions like ext/mysqli. --Kris > > Derick > > -- > http://derickrethans.nl | http://xdebug.org > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > twitter: @derickr and @xdebug > Posted with an email client that doesn't mangle email: alpine
Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
On 12/10/14 01:13, Rasmus Lerdorf wrote: > Keep in mind though that it would be mostly symbolic. The majority of users > get their PHP and extensions from distros. And distros have been separating > out core-bundled extensions for a decade now. Users have absolutely no idea > whether their php-mysql package comes from core or from pecl, nor do they > care. So, unbundling it on our side will have close to zero impact on its > use. In fact, in a weird way it might actually help make people continue to > use it because if we unbundle it and stick it in pecl we would obviously not > have it spew out 'deprecated' notices like we do as of 5.5. I mean, we still > could, of course, but it would be weird having a non-core pecl extension > declare itself deprecated. > > I am not against unbundling it, I just don't think it will achieve what you > hope it will. I may be wrong but certainly SUSE bundles mysql, mysqli and pdo_mysql in the one package and I think most do? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
On Sat, 11 Oct 2014, Nikita Popov wrote: > Hi internals! > > We currently have a number of deprecated features, which we likely want to > remove in PHP 7. I've created a tracking RFC listing deprecated > functionality (if I missed something, please tell): > > https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 > > I expect many of these are no-brainers (like assigning new > by-reference), but other items like removal of ext/mysql may need > additional consideration. > > Unless there are items that are particularly contested, I'd like to handle > the bulk of these in a single vote and only have separate votes for > ext/ereg and ext/mysql, as these are arguably more intrusive. I think there should be a little bit more voting "options" - or rather categories. For example, things like this: # style comments in ini files (since PHP 5.3) I don't think we should remove at all (or why is this even deprecated?! cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
On Sat, 11 Oct 2014, Kris Craig wrote: > On Oct 11, 2014 1:52 PM, "Nikita Popov" wrote: > > > > We currently have a number of deprecated features, which we likely > > want to remove in PHP 7. I've created a tracking RFC listing > > deprecated functionality (if I missed something, please tell): > > > > https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 > > > > I expect many of these are no-brainers (like assigning new > > by-reference), but other items like removal of ext/mysql may need > > additional consideration. > > > > Unless there are items that are particularly contested, I'd like to > > handle the bulk of these in a single vote and only have separate > > votes for ext/ereg and ext/mysql, as these are arguably more > > intrusive. > > +1 on all of that. > > As far as ext/mysql is concerned, I would eagerly vote in favor of removing > it. It performs poorly, is procedural, less secure, doesn't support "is procedural" is however, never a reason to remove something. As most of PHP's function library, is procedural and works just fine. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Big Integer Support
On 12/10/14 02:15, Rowan Collins wrote: > On 11/10/2014 10:13, Lester Caine wrote: >> BIGINT is the SQL99-compliant 64-bit signed integer type > > It's a matter of context. In C, and therefore in related discussions > (which includes the internals of PHP), integers are referred to as > "short" (for 16-bit), "long" (for 32-bit) and "long long" (for 64-bit), > but never as "big". SQL is unusual in calling a 32-bit integer "BigInt" > rather than some variant of "long" or "32", and since we're not > discussing databases here, it's of only marginal relevance. > > I can see why, having spent more time in SQL than C, you might jump to > the wrong meaning of "BigInt", and it might even be worth considering > this potential confusion when writing the end-user documentation for > this new feature, should it be implemented. > > But, as others have said, that's really not an issue which should > dominate the discussion at this stage. There were only two things on my wish list for PHP6 ... Unicode and proper handling of BIGINT. The use of a 64 bit value in databases as the primary key has been long established and a related 64 bit element is timestamp, While the timestamp can be handled as two 32 bit values (on some databases!), the primary key is a 64 bit number. Many database engines started using 64 bit builds years ago and have native 64bit integers, but still handle that on 32bit builds as well. Bringing that key into PHP has always been something of a gamble as to how it will be represented, but the database drivers do seem to line up now. You are right that *I* had miss interpreted Andrea's use of bigint but I have always commented on it in the context of using a 64bit integer key for arrays. In relation to the CURRENT discussion, if a 32bit build is going to default to a 'BigInteger' string rather than a simple 64bit value then there is a problem. I would rather THAT did not happen, but it still leaves the problem of 64bit keys for arrays in 32bit builds. There are many reasons why a 32bit primary key was limiting in databases and while I have no doubt at some point it will be upgraded to 128bit, a 64bit value for timestamps and record counts will last long after most of even you youngsters have past away? BigInteger is a PHP8 problem 64bit array keys is the PHP7 one! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
