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 synt
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 lik
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;
fn(
bits.
Thank you.
Wes
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
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 _really_
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 telling
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
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 doub
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 rea
at 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
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 that's
Ugh. I incorrectly remembered it was one week.
Sorry for the confusion.
Totally missed that. Thank you for linking.
>
I hope I'm not starting a catastrophe. In case,
I'm sorry. :P
Voting will end on 6 December 2016.
Thanks, Wes
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 progr
t/rfc/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)
f SPL Exception, because none of
the existing makes sense to use here, in my opinion.
2016-11-22 21:43 GMT+01:00 Nikita Popov :
> On Tue, Nov 22, 2016 at 6:47 PM, Wes wrote:
>
>> Greetings again PHPeople,
>>
>> I wanted to avoid the discussion for the small improvements I was
>
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 :
> On 22/11/2016 17:32, Wes wrote:
>
>> Okay. But just for the record, it's about very tiny additions... aren't 4
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 already,
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 :
> 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
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 thing altogether to re
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
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.
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 s
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();
(i didn't read the above discussion)
Can we deprecate also the php5-style assert()? It wasn't used a lot anyway.
Thanks :P
Please do this! :)
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.
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.
Chang
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
reimplemen
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.
Yes, you can.
http://php.net/manual/en/language.oop5.magic.php#object.tostring :P
that is actually a good point Marcio.
2017-01-08 21:10 GMT+01:00 Marcio Almada :
> Hi Wes,
>
> 2017-01-08 15:44 GMT-04:00 Wes :
>
>> Yes, you can.
>> http://php.net/manual/en/language.oop5.magic.php#object.tostring :P
>>
>
> It's still not guaranteed that
>
> 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
vote restarted
you guys went slightly off topic :P
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
beco
I do that too... but I feel bad for doing it :P Property accessors would be
great to have...
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.
Amazing how constants are not constant :P
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
r
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){
if(
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 remo
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 - sorry for droppi
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 kno
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 retur
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
comp
> > 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 like
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
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') ?
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");
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."
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 __d
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
filed a bug https://bugs.php.net/bug.php?id=74117
> I'm an imbecile.
It's confirmed. Sorry for the trashy emails and the bug report. Time to go
to bed :P
f you intend to work on it!
Regards, Wes
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;
}
`
#x27;s hopefully 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
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 {} } /
Hi again. There is no BC break, at all.
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 abst
No problem. I instead thank you for checking this, because I forgot to
check it myself (sorry).
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
abstra
Hi, please have a look at https://wiki.php.net/rfc/loop_else first.
It has been discussed already.
And also https://wiki.php.net/rfc/loop_or
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 u
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 = "my_fake_dat
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
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 hel
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 no
Hello PHPeople, I present to you... the shortest RFC ever.
https://wiki.php.net/rfc/deprecate-backtick-operator
Let me know what you think!
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 deprecatio
Please stay on topic. Thank you.
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 ¯\_(ツ)_/¯
░░▄▄███░
░░▄▄░███
░░███▄░▄█▀░█
░░▀█░▄███▀▀░▀███
███▀▀░░▀▀▀█████▀
██░░▄░░░▀▀▄▄███░
▄█▄▄▀█░█▄██▄▄░▀░
░░░▄
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 simpl
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.
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.
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 ==
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));
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 i
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 really
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 array_merge
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
I didn't link it because that page was never updated with the progress we
made :P
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)
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
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
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 in
Nope, it's not. https://3v4l.org/N4LNb It should've been fixed.
Indeed, many people expected it to work already.
Covariance from no-type is already supported, since 7.0
https://3v4l.org/I1hZs
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
>
94 matches
Mail list logo
