Re: [PHP-DEV][RFC][VOTE] Normalize array's "auto-increment" value on copy on write

Totally missed that. Thank you for linking. >

Re: [PHP-DEV][RFC][VOTE] Normalize array's "auto-increment" value on copy on write

Ugh. I incorrectly remembered it was one week. Sorry for the confusion.

[PHP-DEV][RFC][VOTE] Normalize array's "auto-increment" value on copy on write

Hello PHP, I just started the vote on https://wiki.php.net/rfc/normalize-array-auto-increment-on-copy-on-write and I will close it in one week from now >From the discussion (https://externals.io/message/105992) it emerged the intention to make the proposed change even stricter. But, given

Re: [PHP-DEV][RFC] Normalize array's "auto-increment" value on copy on write

knows how to implement it efficiently. For now, my RFC only makes sure that foreign references in particular will receive arrays with normalized and predictable "auto increment" values. Wes

[PHP-DEV][RFC] Normalize array's "auto-increment" value on copy on write

Hello internals, I just published another RFC https://wiki.php.net/rfc/normalize-array-auto-increment-on-copy-on-write Please keep in mind that my intentions are good and I am proposing things in the interest of everybody. Also, I am aware that I might be wrong. If I am, please illustrate the

Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures

Hi Alexandru, I don't think there is intention to do that. In particular with pass by reference. Importing variables by-ref likely will be explicit, given recent discussions on the matter. The new Closures or the old ones might automatically "copy" all variables (by-value) at some point, but I

Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures

Hi Kalle. I hope it's feasible. Unfortunately I don't know much about internals. Any info on the matter would be very appreciated, though :P Anyway, if we can scan the function body to complain about `return null;` when the function is `:void`, surely we can scan just the very top of the function

Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures

Welcome to the first inevitable patronizing message... No, my code is not smelly. If something is smelling for you, check your armpits. Importing 4 variables is not rare. If you think it's rare and should be done differently, maybe you should first actually do something with Closures before

Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures

Hi Kalle, I realize it's going to be a bit odd when binding by value. But it's not that hard to grasp. ``` $a = 123; $closure = function(){ use $a; echo $a; // 123 }; $a = 345; ``` For this reason I specified it is mandatory to have `use` only at the very top (otherwise, it would

Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures

Declaring variables or specifying which ones to import. Essentially it's the same thing, so what gives? It's PHP's syntax, IMHO, that makes the thing irritating to write :D

[PHP-DEV][RFC] Alternative "use" syntax for Closures

. Thank you. Wes

Re: [PHP-DEV] [RFC] Arrow functions / short closures

I like it. Only exception is: ``` fn&() => ...; ``` Which I would prefer to see reserved for the purpose that you've written as: ``` fn() use(&) => ...; ``` The & symbol of "return by ref", should be placed on the right of the parentheses, near the return type: ``` fn(int &$x)&: int => $x;

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

Finally!!! everybody will be able to parse my xml files with embedded php1!1 if I ever wrote one!!! Sorry for the sarcasm, please don't consider this as a personal attack. The whole community (not just you) considers short open tags poison because not XML-compatible... while they use stuff

Re: [PHP-DEV] RFC Draft: Comprehensions

Hi! proposed syntax: > $gen = [for $list as $x if $x % 2 yield $x*2]; > current php + short closures: $gen = () => foreach($list as $x) if($x % 2) yield $x * 2; 1- parentheses could be optional around control structures, so `if(true){}` could be simply `if true{}` 2- "for" could accept the

Re: [PHP-DEV][RFC] Allow void return type variance

I know this too. I am often in touch with Levi and void variance is not covered by his RFC As a matter of fact, if you try to compile that PR void will behave exactly like it does now My RFC targets 7.2 and 7.3 other than 7.4 >

Re: [PHP-DEV][RFC] Allow void return type variance

Covariance from no-type is already supported, since 7.0 https://3v4l.org/I1hZs

Re: [PHP-DEV][RFC] Allow void return type variance

Nope, it's not. https://3v4l.org/N4LNb It should've been fixed. Indeed, many people expected it to work already.

Re: [PHP-DEV][RFC] Allow void return type variance

Hi! PHPUnit 8 changed e.g. ` function setUp(){}` to ` function setUp(): void{} ` and a lot of people did not like being forced to do the same on their `setUp()`. The issue is not PHPUnit adding `void`, but PHP forcing `void` even when it's not necessary. If PHPUnit wants to use void but

[PHP-DEV][RFC] Allow void return type variance

7.4 doesn't make much sense. FTR this is an improvement regardless of PHPUnit, and it's IMO a very reasonable change. Thank you for your time. Wes

[PHP-DEV] IterableFactory pseudo type

Hello everybody and happy new year I was thinking to RFC the following union: ``` typedef IterableFactory = array | IteratorAggregate; ``` As you know, passing Iterators around is a bad idea because one can accidentally end up using them concurrently. For example if one entity is traversing the

Re: [PHP-DEV] [RFC] Spread Operator in Array Expression

Maybe I wasn't clear enough the first time. If you want to merge two maps, you use $a + $b. This functionality already exist. The missing functionality is push / unshift and concat. (And if you really want it, the previously mentioned "ordered map concat" behavior)

Re: [PHP-DEV] [RFC] Spread Operator in Array Expression

I didn't link it because that page was never updated with the progress we made :P

Re: [PHP-DEV] [RFC] Spread Operator in Array Expression

Also my opinion: it should work like push(). If people really want the "ordered map concat" functionality, then it should be an entirely different operator. Good luck

Re: [PHP-DEV] [RFC] Spread Operator in Array Expression

Hi, I worked together with Chris Wright, author of the other RFC covering the same thing. You will find there is very little agreement on how this should work, which is the reason the RFC stalled... not because we didn't try. The most important thing is that we don't want it work like

Re: [PHP-DEV] Non-nullable properties

It's more strict in the proposed rfc. In particular in java the error is allowed to propagate in the program, while here it won't be. In other words if ` $foo->aaa` is uninitialized, you are not allowed to do ` $baz->bbb = $foo->aaa`. In java that's allowed, so in java null pointer deref can

Re: [PHP-DEV] Non-nullable properties

I agree with you. If someone really wants to have an "uninitialized" field on purpose, they should do that using the correct type declaration, i.e.: ?MyType $myNullable = null; When this was started I asked if it was possible to check types right after object has been constructed, but they said

Re: [PHP-DEV] [RFC] User-defined object comparison

not some class, only same comparator function. e.g. this is ok, as __equals is the same for both classes trait X{ function __equals($o){ ... } } class A{ use X; } class B{ use X; } assert((new A) == (new B));

Re: [PHP-DEV] [RFC] User-defined object comparison

some ideas and concerns: - I would like to see this in an extension first, i think it's perfectly doable and people can test it before merging to core - would be nice if compareTo and equals were used only if left operand and right operand used the same comparator function. In other words, $a ==

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

Consider that people dislike writing \strlen(), they will for sure dislike writing u"string". Hence reassigning backticks to unicode strings seemed to me like a possibility.

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

No technical reason. Keep in mind that people dislike... a lot... writing \strlen() (with the leading \) so I thought they would also dislike writing u"unicode" or any other solution that uses more than 2 enclosing characters.

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

Again, the reason is: in case in future PHP wants to use backticks for unicode strings, like javascript. If the community think it's feasible, in PHP 9, 10, whatever, it must be deprecated asap. If you think PHP should use a different syntax for unicode strings in future, you vote no. It's as

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

░░▄▄███░ ░░▄▄░███ ░░███▄░▄█▀░█ ░░▀█░▄███▀▀░▀███ ███▀▀░░▀▀▀█████▀ ██░░▄░░░▀▀▄▄███░ ▄█▄▄▀█░█▄██▄▄░▀░

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

There is not much to say. You either agree with it or you don't. And I wasn't trying to make fun of none of you. Sorry if you consider the version number inappropriate ¯\_(ツ)_/¯

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

Please stay on topic. Thank you.

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

Hi Stas thanks for the feedback. I've added more info for more clarity. It's absolutely impossible to treat notices as errors in PHP, so I assume everybody thinks the same. If someone converts notices to ErrorExceptions or something, it's their fault. A notice in tests is exactly what a

[PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

Hello PHPeople, I present to you... the shortest RFC ever. https://wiki.php.net/rfc/deprecate-backtick-operator Let me know what you think!

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

I just want to add: vote is not very obvious - non internals people are getting too excited about this :P Please consider: People that don't have an IDE that handles the imports automatically, will be effectively forced to prefix \ to everything, which is really ugly. But again, prefixing \ is

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

question was: > Do I get that right that it will then no longer be possible to mock functions from the root namespace during tests? > At least when the functions are "use"d or are explicitly namespaced... > Being able to mock functions like "date" or "time" or "mt_rand" is currently extremely

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

No idea, I'm not really sure what's the difference between E_STRICT and E_DEPRECATED. Yeah the shim is just a rough POC (completely forgot that define() can define in namespaces). Nicolas Grekas on twitter also suggested that we should introduce function_alias() that works like class_alias(). With

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

I get that people want to do that, it's so comfortable. But is it really a good idea? When I have that kind of problem, I use: class Foo{ protected $date = "date"; function getDate(){ return ($this->date)(); } } $mockFoo = new class extends Foo{ protected $date =

[PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

Hello PHPeople. I just published the RFC "Deprecation of fallback to root scope". It is quite a substantial change, but as you can read in the RFC, can be a (basically) transparent one. I'm referring to the possibility to shim it in userland. Essentially, this would move the feature from core to

Re: [PHP-DEV] Allow else after loop structures for,foreach and while?

And also https://wiki.php.net/rfc/loop_or

Re: [PHP-DEV] Allow else after loop structures for,foreach and while?

Hi, please have a look at https://wiki.php.net/rfc/loop_else first. It has been discussed already.

Re: [PHP-DEV][RFC][VOTE] Allow abstract function override

Hi Patrick, this is basically the completion of what Niklas did in his RFC and that PHP 7.0 started. I could've being more clear :) PHP 7 introduced variance (variance from mixed) for returns, then Niklas added the same thing for parameters (variance to mixed) and this extends the support to

Re: [PHP-DEV][RFC][VOTE] Allow abstract function override

No problem. I instead thank you for checking this, because I forgot to check it myself (sorry).

Re: [PHP-DEV][RFC][VOTE] Allow abstract function override

Hi Derick, sorry, previous message was meant to reply to you. There is no BC break, not even subtle. Ocramius' assumption is wrong. The most authoritative one is the innermost and closest ancestor definition. It is like that for classes, it is like that for interfaces, should be like that for

Re: [PHP-DEV][RFC][VOTE] Allow abstract function override

Hi again. There is no BC break, at all.

Re: [PHP-DEV][RFC][VOTE] Allow abstract function override

Yes, yes you are :D Quick reminder:​ ```php interface iA { function bar(stdClass $x); } interface iB extends iA { function bar($x): stdClass; } // OK class cA { function bar(stdClass $x) {} } class cB extends cA { function bar($x): stdClass {} }

[PHP-DEV][RFC][VOTE] Allow abstract function override

not too hard to implement. https://wiki.php.net/rfc/allow-abstract-function-override I've decided to start the vote. It will end two weeks from this message, on 10th April 2017. Thanks in advance for participating. Wes

Re: [PHP-DEV][RFC][DISCUSSION] Allow abstract function override

Not sure i get what you mean. With "abstract functions" I include also those in interfaces. I haven't tried 7.2 yet, but i think what I'm proposing is already supported (+ kelunik's RFC): ``` interface A{ function x(stdClass $foo); } interface B extends A{ function x($foo): stdClass; }

[PHP-DEV][RFC][DISCUSSION] Allow abstract function override

intend to work on it! Regards, Wes

Re: [PHP-DEV] Change debug_zval_dump to return the dump unaffected by __debugInfo?

> I'm an imbecile. It's confirmed. Sorry for the trashy emails and the bug report. Time to go to bed :P

Re: [PHP-DEV] Change debug_zval_dump to return the dump unaffected by __debugInfo?

filed a bug https://bugs.php.net/bug.php?id=74117

Re: [PHP-DEV] Change debug_zval_dump to return the dump unaffected by __debugInfo?

Actually, scratch that, I'm an imbecile... function __debugInfo(){ return (array)$this; } ...would work just fine to access the old style dump except that it doesn't. Did you notice that (array)$object cast uses __debugInfo? https://3v4l.org/VKbPj

[PHP-DEV] Change debug_zval_dump to return the dump unaffected by __debugInfo?

Hello Internals. Today I'm fighting with some code that I think uses var_dump() and output buffering to create the output for __debugInfo... or something like that - I'm not really interested into finding the cause :P Anyway, It's not the first time I find myself paralyzed by a slightly broken

Re: [PHP-DEV] Re: [RFC] Deprecate and Remove Bareword (Unquoted) Strings

Great! We can get rid of one of the most ridiculed "features" of the language :D http://php.net/manual/en/language.types.array.php#language.types.array.donts "This is wrong, but it works."

Re: [PHP-DEV] Not autoloading functions

Hi Rowan, I probably wasn't clear enough. How is having to write use namespace Foo\Bar\Baz; better than require_once("../Foo/Bar/Baz/functions.php");

Re: [PHP-DEV] Not autoloading functions

Curious that those who are posting here put all functions in the same file. So, why don't you just require_once('Namespace/functions.php') ?

Re: [PHP-DEV] Not autoloading functions

I suppose that is because they use just few functions. I don't think you would want to have 20-30 functions in the same file :P

Re: [PHP-DEV] Not autoloading functions

> > old applications could maintain compatibility only > > by adding a simple autoloader that would alias the global > function/constant > > into the calling namespace > > So as a side-effect of calling any function, my namespace would get > polluted with all sorts of random names? That sounds

Re: [PHP-DEV] Allow "static" type

I completely agree with what you said. Static inheritance is wrong. Static members shouldn't be inherited. This is what I think and probably what you think too. But it's too late to fix this. I don't think it's worth changing the expectations of the users, which rely on inherited members to be

Re: [PHP-DEV] Allow "static" type

Hi​, static could be definitely a valid return type, but I don't see this happening for parameters, for the same reasons this is disallowed: class A{ function bar(A $a){} } class B extends A{ function bar(B $b){} } // must be contravariant, but B is covariant to A However again, it works as

Re: [PHP-DEV][RFC][VOTE] Throwable error code's type generalization

Closing this. Thanks to the voters! Markus: sorry if i didn't answer, i didn't get the notification. I realize now it wasn't really clear. Patch would've changed Error and Exception constructors only, from int to "mixed". And someone else would have had to write it, because I have no internals

Re: [PHP-DEV] [RFC][VOTE] Trailing commas in all list syntax

Can I apologize already for the imminent failure? :P I think it's very much ok on parameters and especially arguments. I don't really care about the others. 2017-01-27 17:05 GMT+01:00 Sammy Kaye Powers : > Hello my internals friends! > > After a 2 week (ahem... 1 year & 3 month -

Re: [PHP-DEV] Not autoloading functions

Importing functions from a static class would equally require to have all functions in the same file. I was proposing an alternative to that, not "symbol to file" autoloading. Though, I know that problem well, sadly. I've suggested PHP should just deprecate the fallback to root namespace, and

Re: [PHP-DEV] Not autoloading functions

An alternative (which I haven't properly developed yet). Thoughts? ``` define_autoload(AUTOLOAD_NS, function($ns){ if($ns === '\A\B\C'){ echo "LOADING ABC\n"; require(__DIR__ . $ns . '\functions_and_constants.php'); } }); define_autoload(AUTOLOAD_NS, function($ns){

Re: [PHP-DEV] Class Constant Finalization

They don't belong to a class only, but to a class and all its descendants. Ideally, descendants should not inherit constants (or anything static), but we can't change that now, so final could make sense here. Basically, they should work exactly like static fields, except that static fields can be

Re: [PHP-DEV] Class Constant Finalization

Amazing how constants are not constant :P

Re: [PHP-DEV][RFC][VOTE] Throwable error code's type generalization

Voting will end on Jan 27, if you are ok with that. I have been told one week wasn't enough, then also the mailing list problems happened. This should be enough to give everyone the opportunity to vote. Thank you.

Re: [PHP-DEV] Unsetting declared fields

I do that too... but I feel bad for doing it :P Property accessors would be great to have...

[PHP-DEV] Unsetting declared fields

Hello elephpants. Currently PHP allows explicitly declared fields (eg public $foo = 10;) to be removed entirely through unset (eg unset($obj->foo)). Now that isn't really an issue as properties in php are currently untyped and therefore nullable; at worst you would get a notice. But it would

Re: [PHP-DEV] Explicit constructor call and polymorphic dispatch

you guys went slightly off topic :P

Re: [PHP-DEV][RFC][VOTE] Throwable error code's type generalization

vote restarted

Re: [PHP-DEV] Explicit constructor call and polymorphic dispatch

> > I am baffled that this (still) works: > __clone was special cased in 5.x, but special case was removed in 7.0 means that previously you couldn't do publicly $obj->__clone(); now you can and, yes, it's as dangerous as it looks however, the special case was removed for a reason that i'm sure is

Re: [PHP-DEV][RFC][VOTE] Throwable error code's type generalization

that is actually a good point Marcio. 2017-01-08 21:10 GMT+01:00 Marcio Almada <marcio.w...@gmail.com>: > Hi Wes, > > 2017-01-08 15:44 GMT-04:00 Wes <netmo@gmail.com>: > >> Yes, you can. >> http://php.net/manual/en/language.oop5.magic.php#object.tostring

Re: [PHP-DEV][RFC][VOTE] Throwable error code's type generalization

Yes, you can. http://php.net/manual/en/language.oop5.magic.php#object.tostring :P

Re: [PHP-DEV][RFC][VOTE] Throwable error code's type generalization

I don't see how objects are less important than strings. Many of us have enum-ish kind of objects in their code, even if php doesn't support them natively. We could consider using them as error code if this was allowed.

Re: [PHP-DEV][RFC][VOTE] Throwable error code's type generalization

Deprecating it is also a lot of effort for very little improvement. People would be forced to fix all their constructors calls just to skip the parameter. Personally I would be very annoyed by such a pointless change. Plus those that actually do use the code will be forced eventually to

Re: [PHP-DEV][RFC][VOTE] Throwable error code's type generalization

Hi Marco \o, linking to the discussion thread http://externals.io/thread/573 because I don't have much more to add. I think the throwable's code is almost never used regardless, but this could give users more opportunities to do something useful with it as Niklas stated in previous thread.

[PHP-DEV][RFC][VOTE] Throwable error code's type generalization

Greeting fellow elePHPants and happy new year. I've just started the vote for the RFC in subject. You can find it here: https://wiki.php.net/rfc/throwable-code-generalization Hope it's all fine because this is my first RFC... :P Voting will end 13 Jan at 5 PM (UTC). Thank you.

Re: [PHP-DEV] Revisit RFC “Property Accessors Syntax 1.2”

Please do this! :)

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.2

(i didn't read the above discussion) Can we deprecate also the php5-style assert()? It wasn't used a lot anyway. Thanks :P

Re: [PHP-DEV][RFC][DISCUSSION] - Throwables error code's type generalization

Will be nice to have regardless if PHP gets stuff like enums. It's not just a dirty fix. Strictly speaking it is not a BC change because `int` is not actually enforced at all. Also this would be a problem in other languages... function bar(): int{ mixed $code = (new MyException)->getCode();

Re: [PHP-DEV][RFC][DISCUSSION] - Throwables error code's type generalization

Yo, Marco :P I don't need to add any contextual data, I'm just trying improve consistency by formalizing what PHP already does. I think it's the right way to fix this because I don't think changing PDO is ever going to happen. You either special case PDO in your code or formalize the special case

[PHP-DEV][RFC][DISCUSSION] - Throwables error code's type generalization

Good morning nice internals PHPeople, I have just written a new RFC. I believe is mostly about cosmetic changes, as what is being proposed is probably already informally supported by PHP. I would like your opinion about it: https://wiki.php.net/rfc/throwable-code-generalization Thank you.

Re: Fwd: [PHP-DEV] RFC: Anonymous Class Lexical Scope

One important thing I'd like to have here is importing the "outer" $this. e.g.: public function bar(){ return new class use($this as $that){ public function test(){ return $this->that; } }; } And I dislike how this would look with NikiC's proposal:

Re: [PHP-DEV] [RFC] ArrayIterator improvements

2016-11-25 19:27 GMT+01:00 Stanislav Malyshev : > > Now the RFC says " if the given key is present in the array the method > would successfully return null". While technically in PHP not returning > value and returning NULL is the same thing, I'd just omit the whole > return

Re: [PHP-DEV] [RFC] ArrayIterator improvements

Hello PHPeeps, I've updated the RFC! Have a look at it, please! (Sorry for the engrish) Wes 2016-11-23 15:29 GMT+01:00 Wes <netmo@gmail.com>: > I'm fine with anything as... well, being picky on this won't change the > fact that SPL's design and exceptions are a mess :P >

Re: [PHP-DEV] [RFC] ArrayIterator improvements

I'm fine with anything as... well, being picky on this won't change the fact that SPL's design and exceptions are a mess :P If you are ok with that, I'm modifying soon the RFC, so that seekKey() would throw OutOfBoundsException instead of returning bool. Thoughts? @Ryan I've noticed that

Re: [PHP-DEV] [VOTE] ArrayIterator improvements

Just wanted to save everybody's time. 4 weeks seemed an enormity for that. But obviously there is no hurry. 2016-11-22 21:34 GMT+01:00 Rowan Collins <rowan.coll...@gmail.com>: > On 22/11/2016 17:32, Wes wrote: > >> Okay. But just for the record, it's about very tiny add

Re: [PHP-DEV] [RFC] ArrayIterator improvements

Exception, because none of the existing makes sense to use here, in my opinion. 2016-11-22 21:43 GMT+01:00 Nikita Popov <nikita@gmail.com>: > On Tue, Nov 22, 2016 at 6:47 PM, Wes <netmo@gmail.com> wrote: > >> Greetings again PHPeople, >> >> I wanted t

[PHP-DEV] [RFC] ArrayIterator improvements

/arrayiterator-improvements Again this is my first RFC, and I hope I'm doing nothing wrong this time :P Thanks again, Wes (and special thanks to Room11 for their feedback about the RFC process)

Re: [PHP-DEV] [VOTE] ArrayIterator improvements

Okay. But just for the record, it's about very tiny additions... aren't 4 weeks for that too much? Also, in my defense, I'm not the first doing that. I don't remember exactly but there was a RFC about ext/intl it was put straight to votes as it was about small additions. I'm not a internals

[PHP-DEV] [VOTE] ArrayIterator improvements

not starting a catastrophe. In case, I'm sorry. :P Voting will end on 6 December 2016. Thanks, Wes