[PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList

[Michał Brzuchalski]

Hi Internals,

I'd like to start a discussion period for my RFC which proposes to change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.

The RFC is here https://wiki.php.net/rfc/change-terminology-to-excludelist

Discussions should remain on the list.
Any emails sent directly are likely to be replied to on the list.

Cheers,
Michał Marcin Brzuchalski

Re: [PHP-DEV] Remove LSP checks on static methods?

[Michał Brzuchalski]

wt., 16 cze 2020 o 09:50 Nikita Popov  napisał(a):

> On Tue, Jun 16, 2020 at 8:59 AM Mike Schinkel  wrote:
>
> > Hi internals,
> >
> > Given that there appears to be some appetite to reduce checks for
> > inappropriate signatures[1] I am wondering if anyone has strong opinions
> —
> > pro or con — on removing checks for static methods?
> >
> > My primary use-case where I would like to see checked relaxed is for
> > static methods used as factory methods[2].
> >
> > Per [3] it seems that all but the least upvoted answer argues that LSP
> > applies to instances, not static methods.
> >
> > Per [4] it seems that all upvoted answers agree that constructors should
> > not be constrained by LSP, and since a factory method is a form of a
> > constructor it would seem that if constructors do not require LSP then
> > factory methods would not either.
> >
> > Does anyone see any issues with relaxing these checks for static methods
> > that would have them downvote an RFC on the topic?
> >
>
> Hi Mike,
>
> The problem here is that static methods signatures are subject to LSP if
> they are used in conjunction with late static binding (LSB):
>
> class A {
> public static function test() {
> static::method();
> // May call A::method(), B::method() or any child.
> // Signature must match for this to be sensible!
> }
> }
> class B extends A {
> }
>
> I do agree that the current situation is sub-optimal, because certainly not
> all static methods actually are used with LSB. But we do not presently
> distinguish these cases.
>
> If that problem can be addressed in some way, then I agree that (non-LSB)
> static methods should be exempt from LSP, just like constructors are.
>

In that case maybe a core annotation like "Override" to relax checks ??
That way it'd say explicitly that it was intentional override.

Cheers,
Michał Marcin Brzuchalski

Re: [PHP-DEV] Remove LSP checks on static methods?

[Michał Brzuchalski]

Hi Mike,

wt., 16 cze 2020 o 08:59 Mike Schinkel  napisał(a):

> Hi internals,
>
> Given that there appears to be some appetite to reduce checks for
> inappropriate signatures[1] I am wondering if anyone has strong opinions —
> pro or con — on removing checks for static methods?
>
> My primary use-case where I would like to see checked relaxed is for
> static methods used as factory methods[2].
>
> Per [3] it seems that all but the least upvoted answer argues that LSP
> applies to instances, not static methods.
>
> Per [4] it seems that all upvoted answers agree that constructors should
> not be constrained by LSP, and since a factory method is a form of a
> constructor it would seem that if constructors do not require LSP then
> factory methods would not either.
>
> Does anyone see any issues with relaxing these checks for static methods
> that would have them downvote an RFC on the topic?
>

I can only see a one huge BC break.
What you suggest would require the deprecation of static methods on
interfaces.
Currently, you can declare a static method on an interface, like this:

interface Foo {
public static function create(): self;
}
class Bar implements Foo {
public static function create(): self { return new self(); }
}
var_dump(Bar::create());

Hence it'll be a huge BC break and the first reason downvote to the RFC I
guess.

Cheers,
Michał Marcin Brzuchalski

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Michał Brzuchalski]

wt., 9 cze 2020 o 13:56 Benjamin Eberlei  napisał(a):

> On Thu, Jun 4, 2020 at 1:55 AM Theodore Brown 
> wrote:
>
> > Hi internals,
> >
> > I discussed the syntax for attributes further with Benjamin, Martin,
> > and several other internals developers off-list, and with their
> > feedback completed an RFC proposing to use the shorter `@@` syntax
> > instead of `<<>>` for attributes in PHP 8.
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax
> >
> > The goal is not to bikeshed over subjective syntax preferences,
> > but to address several concrete shortcomings related to verbosity,
> > nested attributes, confusion with generics and other tokens, and
> > dissimilarity to other common languages.
> >
>
> Larry's suggestion about #[Attr] makes an important argument about allowing
> to declare attributes in code in PHP 7 in a forward compatible way that has
> not been brought up before.
>
> /** @ORM\Entity */
> #[ORM\Entity]
> class User {}
>
> This code would work on PHP 7 and 8.
>
> The #[] syntax would have about equally low breaking potential as @@. It
> would be the same syntax as Rusts, and close to C++/C# syntax.
>

I just noticed a power of Rusts outer attributes which this syntax count
follow in a future.
Following outer attributes in Rust's we could introduce in a future syntax
like

Re: [PHP-DEV] Re: Making all Traversables an Iterator or IteratorAggregate

[Michał Brzuchalski]

wt., 9 cze 2020, 15:33 użytkownik Nikita Popov 
napisał:

> On Tue, May 12, 2020 at 10:26 AM Nikita Popov 
> wrote:
>
> > On Wed, Mar 11, 2020 at 10:50 AM Nikita Popov 
> > wrote:
> >
> >> Hi internals,
> >>
> >> Userland classes that implement Traversable must do so either through
> >> Iterator or IteratorAggregate. The same requirement does not exist for
> >> internal classes: They can implement the internal get_iterator
> mechanism,
> >> without exposing either the Iterator or IteratorAggregate APIs. This
> makes
> >> them usable in get_iterator(), but incompatible with any Iterator based
> >> APIs.
> >>
> >
> > This should have said: "This makes them usable in foreach(), but
> > incompatible with any Iterator based APIs."
> >
> > A lot of internal classes do this, because exposing the userland APIs is
> >> simply a lot of work. I would like to add a general mechanism to make
> this
> >> simpler: https://github.com/php/php-src/pull/5216 adds a generic
> >> "InternalIterator" class, that essentially converts the internal
> >> get_iterator interface into a proper Iterator. Internal classes then
> only
> >> need to a) implement the IteratorAggregate interface and b) add a
> >> getIterator() method with an implementation looking like this:
> >>
> >> // WeakMap::getIterator(): Iterator
> >> ZEND_METHOD(WeakMap, getIterator)
> >> {
> >> if (zend_parse_parameters_none() == FAILURE) {
> >> return;
> >> }
> >> zend_create_internal_iterator_zval(return_value, ZEND_THIS);
> >> }
> >>
> >> This allows internal classes to trivially implement IteratorAggregate,
> >> and as such allows us to enforce that all Traversables implement
> Iterator
> >> or IteratorAggregate.
> >>
> >
> > Does anyone have thoughts on this change? Mostly this is a feature for
> > extensions, but also user-visible in that a bunch of classes will switch
> > from being Traversable to being IteratorAggregate.
> >
> > We may also want to convert some existing Iterators to
> IteratorAggregates.
> > For example SplFixedArray currently implements Iterator, which means that
> > it's not possible to have nested loops over SplFixedArray. We could now
> > easily fix this by switching it to use IteratorAggregate, which will
> allow
> > multiple parallel iterators to work on the same array. Of course, there
> is
> > BC break potential in such a change.
> >
> > There's some bikeshed potential here regarding the class name. I picked
> > "InternalIterator" as an iterator for internal classes, but "internal
> > iteration" is also a technical term (the opposite of "external
> iteration"),
> > so maybe that name isn't ideal.
> >
>
> Unfortunately this bikeshed remains unpainted... The proposed names were:
>
>  1. InternalIterator
>  2. ZendIterator
>  3. IteratorForExtensionClassImplementations
>  4. EngineIterator
>
> I'm somewhat partial to the third option, with a less verbose name:
> IteratorForExtensions.
>

ExtensionsIterator??

BR,
Michał

>

[PHP-DEV] Re: [RFC][VOTE] PHP Namespace in core

[Michał Brzuchalski]

śr., 3 cze 2020 o 09:49 Michał Brzuchalski 
napisał(a):

> pt., 22 maj 2020 o 08:14 Michał Brzuchalski 
> napisał(a):
>
>> Hi Internals,
>>
>> We have just opened the vote on the PHP namespace in core RFC. The voting
>> will be
>> open for two weeks, until 2020-06-05 06:00 UTC.
>>
>
> Heads-up. We will end the vote soon.
> If anyone may have not decided yet or would like to change their mind,
> this is the last moment.
> You're the one who rocks here!
>

Voting is now closed.
The proposed RFC was rejected with 19 votes in favour and 24 against.
Thank you all for participating.

Cheers,
Michał Brzuchalski

[PHP-DEV] Re: [RFC][VOTE] PHP Namespace in core

[Michał Brzuchalski]

pt., 22 maj 2020 o 08:14 Michał Brzuchalski 
napisał(a):

> Hi Internals,
>
> We have just opened the vote on the PHP namespace in core RFC. The voting
> will be
> open for two weeks, until 2020-06-05 06:00 UTC.
>

Heads-up. We will end the vote soon.
If anyone may have not decided yet or would like to change their mind, this
is the last moment.
You're the one who rocks here!

Cheers,
Michał Brzuchalski

[PHP-DEV] [RFC][VOTE] PHP Namespace in core

[Michał Brzuchalski]

Hi Internals,

We have just opened the vote on the PHP namespace in core RFC. The voting
will be
open for two weeks, until 2020-06-05 06:00 UTC.

Link: https://wiki.php.net/rfc/php-namespace-in-core#vote

Cheers,
Michał Marcin Brzuchalski

[PHP-DEV] Re: [RFC][DISCUSSION] PHP Namespace in core

[Michał Brzuchalski]

Hi Internals,

I'm really sorry for the long delay on this topic.

I think it's time to vote since there seems like no further discussion is
needed.

*So head's up!* I plan to open this topic for a vote.
The vote will be simple Yes/No and requires to be accepted by 2/3 votes as
always.

Voting will open Tomorrow on *May 22nd around 06:00 UTC*
and will remain open for 14 days until *4th of June.*

Cheers,
--
Michał Marcin Brzuchalski
/For the fame and glory of PHP!!/


śr., 15 kwi 2020 o 14:29 Michał Brzuchalski 
napisał(a):

> Hi internals,
>
> I hope you're doing well.
>
> I'd like to announce the PHP Namespace in core RFC for discussion.
> The RFC is authored by me together with George Peter Banyard and it's
> purpose
> is nothing more like to allow the use of PHP Namespace in the core.
>
> The RFC is described at https://wiki.php.net/rfc/php-namespace-in-core
>
> Best Regards,
> Michał Brzuchalski
>

Re: [PHP-DEV] Re: Enchant 2

[Michał Brzuchalski]

Hi Christoph,

śr., 29 kwi 2020 o 11:52 Christoph M. Becker  napisał(a):

> Apparently, not much has been changed in the meantime, besides that new
> Enchant 2 releases are rolled out regularly.  The latest release of
> Enchant 1 (1.6.1) happened on 2017-02-08, and I don't expect to see new
> Enchant 1 releases.  This basically means that we rely on an
> unmaintained library.  So if nobody is interested in bringing
> ext/enchant up-to-date with Enchant 2, it might be best to unbundle the
> extension.
>
> Thoughts?
>

TIL there's a spell check ext in PHP.
I've never used it and actually was asking myself why is it in the core.
I would vote for unbundling of it.

Cheers,
Michał Brzuchalski

Re: [PHP-DEV] Typed callable properties

[Michał Brzuchalski]

Hi Benas,

my responses below.

śr., 22 kwi 2020 o 19:17 moliata  napisał(a):

> Hello,
>
> thank you for an opinion as well! While I do fully agree that callable type
> needs to be improved with features such as typedefs, I found a couple of
> problems in your response.
>
> First of all, I wouldn't say that the callable type provides little-to-no
> information like the resource type. A resource can only be made by specific
> functions such as `fopen()` and are bound to specific use
> cases/implementations
> e. g. MySQL resources are only for MySQL database access. Meanwhile,
> callables
> can be made "freely" (couldn't find a better word :-)) like integers or
> booleans and also in some cases don't have an exact function signature. One
> such example I mention in the next paragraph.
>

I only said that it brings as much value as a resource type in usage
context.

Given a resource type constraint on function argument doesn't say anything
to you
as a consumer, you cannot just use that resource without knowledge of its
type
the only thing you could do is calling a get_resource_type(resource
$resource) function.

The same applies to callable, given callable like: 'strtolower',
[DateTimeImmutable::class, 'createFromFormat']
or fn(int $x): $x*2; and when that came to your function with callable type
constraint
you also don't know how to use it without some reflection inspection cause
the type doesn't bring much value.

While fulfilling for eg. delegate gives you guarantee that when a
callable/closure is passed it matches
your expectations and you can use it right away without reflection
inspections.
You no longer need additional data to use the variable which applies to
callable and resource as well.

Speaking of a snippet you showed, I'm not sure how that implementation would
> work with "dynamic" callables. For example let's assume we have a framework
> that allows registering routes with placeholders to controllers, like this:
> `$router->register('/post/{id}', [$controller, 'show']); // this would
> pass a
> single parameter to the callable`
> `$router->register('/user/{id}/post/{id}', [$controller, 'showFromUser']);
> //
> this would pass two parameters to the callable`
> ...in this case, we can't know how many placeholders/parameters a function
> can
> have as that depends on how many placeholders are in the string. A
> framework
> can only resolve these at runtime.
>

True. In this case, it'd be hard to create a static constraint for
callable/closure check
but actually this is not the case we're looking for. Things where mentioned
delegate
match perfectly is the places where your expectations to the
callable/closure type
are static and known at the time when writing code.

Given that in a situation when the input and the output types are known
this would bring the benefit of runtime check before use.

Cheers,
Michał Brzuchalski

Re: [PHP-DEV] Typed callable properties

[Michał Brzuchalski]

Hi all,

śr., 22 kwi 2020 o 16:29 Dan Ackroyd  napisał(a):

> On Tue, 21 Apr 2020 at 14:08, moliata  wrote:
> >
>
> > I wanted to ignite a friendly discussion whether
> > PHP should allow typed callable properties.
>
> IMO no.
>
>
I agree, a callable brings as much information as a resource type - you
know the type
but are unable to use it without additional information.


> Trying to fix the problems with callables would be a huge amount of
> work, and not actually give that much benefit. Even just documenting
> the problems with callables* is a non-trivial amount of work, and I
> suspect there are many horrors lurking with the SPL code related to
> them.
>
> > I believe we should look into...
>
> I'm pretty sure that choosing a different problem to solve that:
>
> * would be easier to solve.
> * provide more benefit in the long term.
> * not require breaking a lot of userland + internal code immediately,
> but instead allow for migration over a longer period.
>

I was pinged by Dan with typedef topic nearly 3 weeks ago and then started
thinking of the way to define callable types with some initial
implementation.
I chose pattern known from other languages like C# where there are types
known as delegates.

And so far got to the last line of snippet below where I have to figure out
some clever type checking with closure:

delegate Reducer (?int $sum, int $item = 0): int;

class Foo implements Reducer {
public function __invoke(?int $sum, int $item = 0): int {
return ($sum ?? 0) + $item;
}
}
function reduce(Reducer $reducer) {
var_dump($reducer(0, 5));
}
reduce(new Foo());
reduce(fn(?int $sum, int $item = 0): int => 8);

The delegate declaration resolves to an interface with __invoke method
which therefore can be easily checked
when the invokable object passed and that information can be easily cached.
Probably it can be cached also for closures
and functions but didn't get so far with the implementation yet.

I was also asked why not a general use typedef which can be used to alias
any kind of type not only a callable.
But the reason why I chose delegates was that IMO typedef is more like an
aliasing mechanism, which means
all that is possible to be aliased should also be possible to be unaliased
and pasted in all type constraints used in
function/method parameters as well as class properties.

Meaning if we allow: typedef reducer = callable(?int $sum, int $item = 0):
int;
We should also allow: function(callable(?int $sum, int $item = 0): int
$reducer) {}
Which IMO looks too verbose and that's why I think a delegate might be a
good idea as a way to provide
callable types checking.

Any thoughts are highly appreciated!

Cheers,
Michał Brzuchalski

Re: [PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core

[Michał Brzuchalski]

Hi Benjamin,

pon., 20 kwi 2020 o 14:06 Benjamin Eberlei  napisał(a):

> Hi Michał, George,
>
> On Wed, Apr 15, 2020 at 2:29 PM Michał Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
>> Hi internals,
>>
>> I hope you're doing well.
>>
>> I'd like to announce the PHP Namespace in core RFC for discussion.
>> The RFC is authored by me together with George Peter Banyard and it's
>> purpose
>> is nothing more like to allow the use of PHP Namespace in the core.
>>
>> The RFC is described at https://wiki.php.net/rfc/php-namespace-in-core
>
>
> I think the php namespace for core is important to have, especially for
> features that have more than a single, but multiple classes, grouping them
> in a PHP internal namespace will be helpful to avoid weird prefixing.
>
> With the Attributes RFC in mind, an earlier draft has used the namespace
> PHP\Attributes that a few contributors rightly mentioned is a bad idea
> without project wide standardization first.
>
> For my taste, the RFC is great except the "A chance to clean up poor
> design/naming decisions" section. It goes into politics and controversial
> ideas that essentially are outside the scope of the RFC itself. So while
> SPL and Reflection would benefit if we had the namespace before those APIs,
> I am not sure they drive down the point of why we need this:
>
> a.) Instead of changing SPL I believe most would pretty much agree that we
> just need a complete replacement with a better API (pointing towards phpds
> here might be a better example)
> b.) Moving some new parts of Reflection into the namespace while keeping
> others in the main namespace is extremely confusing, and we shouldn't
> confuse users that way. Realistically this is an issue thats not going to
> be changed.
>
> I do like the Frame example, similar to token_get_all returning an array,
> debug_backtrace could benefit from an object based representation. I would
> reluctantly call it a "toy example", it is an actual example or not?
>

The example with the Frame is something I'm thinking about to propose and
implement.

About the changing SPL. Bear in mind that the current proposal is only
about an agreement to allow the use of PHP namespace in the core.
@Benjamin: You suggest to skip the examples and arguments regarding poor
design/naming decisions with Reflection API ?

Those examples are put in the RFC to help understand the argumentation and
the result of this RFC should be the agreement that any future RFC
proposing an introduction of the tightly coupled with the PHP engine symbol
(and to mention the ones with PhpToken and PhpAttribute and family
could be perfect candidates) should not worry for the proposal to be
rejected because of the use of PHP namespace in core symbols.

BR,
Michał Brzuchalski

Re: [PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core

[Michał Brzuchalski]

Hi Mike

wt., 21 kwi 2020 o 07:29 Mike Schinkel  napisał(a):

> I have been wondering for a while why PHP does not officially recognize a
> \PHP namespace.
>
> The inconsistency people have mentioned feels like a fair tradeoff for
> allowing new core classes to be cleanly-named and easier to understand.
>
> And a \PHP namespace would allow RFCs to never need worry about
> conflicting with userland class names again.
>
> The one thing I would ask the authors:
>
> - Why limit it to "tightly coupled to the PHP engine?"
> - Why not just say "any new core classes that are approved to use it?"


In the past, there were some proposals which treated about core namespace
proposing to include most of the core symbols in a structured way.
These proposals always failed for some reason.

This proposal tries to convince internals to use PHP namespace in the core
for tightly coupled to the PHP engine types
which could be placed there without a risk to be unbundled in a future what
would cause a need to rename them back.
Therefore we think that these along with the arguments in the proposal are
the best ones to agree for now.

BR,
Michał Brzuchalski

Re: [PHP-DEV] Type hints in array destructuring expressions

[Michał Brzuchalski]

Hi Nicolas,

czw., 16 kwi 2020 o 12:48 Nicolas Grekas 
napisał(a):

>
> > https://wiki.php.net/rfc/typehint_array_desctructuring
>>
>
> Thanks, Enno, I like it a lot!
> I hope the implementation won't find any blocker.
>
>
>
>> I fear that if you go that path people would automatically expect it to be
>> possible to write:
>>
>> int $id = $data['id'];
>> int $id = getIdFromData($data);
>>
>
> That would be a nice addition I guess - maybe for a separate RFC to keep
> the focus clear on this one.
>
>
>
>> And then expect the $id to behave more like typed property with type
>> guard.
>>
>
> I would not expect the type guard on my side, like function arguments
> don't provide type guards and also because this is PHP: runtime checks slow
> down the engine. Thus I would expect this to be guarded by static type
> analyzers for ppl who care (I'm not sure it matters personally, see SSA
> transformations), and on assignation otherwise to balance perf vs runtime
> overhead. (Note that the expectation you describe is a valid one, I'm just
> explaining that a different expectation exists, and why)
>
>
Agree this would slow things down but if it could be potentially type
checked on the assignment with type constraint in front of the variable
name I think that would be a neat feature.
So to work as a function parameter but not like a typed property.

Cheers,
Michał Brzuchalski

Re: [PHP-DEV] Type hints in array destructuring expressions

[Michał Brzuchalski]

Hi Enno,

czw., 16 kwi 2020 o 12:20 Enno Woortmann  napisał(a):

> Hi together,
>
> as the voting for the "Type casting in array destructuring expressions"
> shows a clear direction to be declined (sad faces on my side, I really
> would've liked it as a feature completion of the casting feature set
> without the need for a really new syntax, as the parser also already
> coverred it, but ok, time to continue :D ), combined with a strong
> interest for the topic "type checks in array destructuring expressions"
> (as well in the discussion as in the vote) I've set up a first draft of
> an RFC covering this topic:
>
> https://wiki.php.net/rfc/typehint_array_desctructuring
>
> The discussion around the casting in array destructuring brought up the
> idea to perform regular type checks in array destructuring expressions.
> This RFC proposes a new syntax to type hint a variable inside an array
> destructuring expression:
>
> $data = [42, 'Example', 2002];
> [int $id, string $data, int $year] = $data;
>
>
I fear that if you go that path people would automatically expect it to be
possible to write:

int $id = $data['id'];
int $id = getIdFromData($data);

And then expect the $id to behave more like typed property with type guard.
At least this is me what would expect from putting a type in from of
variable name
like in array destructuring example.

Why? Cause it has a type constraint in from of variable name just like
typed properties have.

Cheers,
Michał Brzuchalski

Re: [PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core

[Michał Brzuchalski]

Hi Derick,

śr., 15 kwi 2020 o 15:51 Derick Rethans  napisał(a):

> On Wed, 15 Apr 2020, Michał Brzuchalski wrote:
>
> > Hi internals,
> >
> > I hope you're doing well.
> >
> > I'd like to announce the PHP Namespace in core RFC for discussion.
> > The RFC is authored by me together with George Peter Banyard and it's
> > purpose
> > is nothing more like to allow the use of PHP Namespace in the core.
>
> I think a "may" is not a clever way forwards. I think that if you want
> to use the PHP namespace for engine specific things (like
> Attribute/Token), then they must all use that, or none.
>

You mean if we want to introduce PHP namespace we should also propose
immediately to move
engine specific things (like Attribute/Token) into proposal?

If so then we should search for the rest of engine specific things which
will include then
many interfaces and classes like:
1. Traversable, Iterator, IteratorAggregate - cause these are used in
foreach statements
2. ArrayAccess - cause this one is required to accept r/w by dimension
(offset* - methods)
3. Serializable, __PHP_Incomplete_Class ?! - cause this is used in
serializing/deserializing and this is bound to magic methods in classes
4. stdClass - cause this is a default class of the object which is produced
when an array is cast to (object)
5. Closure, Generator - cause these are also tightly coupled with the engine
6. Throwable, etc. - just for consistency with the rest from
https://www.php.net/manual/en/reserved.classes.php
and https://www.php.net/manual/en/reserved.interfaces.php

Is that what you mean?

Cheers,
Michał Brzuchalski

Re: [PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core

[Michał Brzuchalski]

Hi Marcio,

śr., 15 kwi 2020 o 18:39 Marcio Almada  napisał(a):

> >
> > Hi internals,
> >
> > I hope you're doing well.
> >
> > I'd like to announce the PHP Namespace in core RFC for discussion.
> > The RFC is authored by me together with George Peter Banyard and it's
> > purpose
> > is nothing more like to allow the use of PHP Namespace in the core.
> >
> > The RFC is described at https://wiki.php.net/rfc/php-namespace-in-core
> >
> > Best Regards,
> > Michał Brzuchalski
>
> Hello,
>
> Even though I'm fond to the idea of languages having the official
> stdlib contained
> into a single space, there seems to be no practicality on a \PHP namespace
> usage
> at this point IMMO.
>
> We would be in a situation where things are either mixed in and out
> the new namespace
> - Should I `use function PHP\{json_encode, json_decode}` or was it in
> the root??? - or
> everything that already exists must first receive an alias into this
> new namespace, to allow
> consistency... but then there would probably be no plans ever to
> actually move existing stuff
> into the new prefix in the future.
>
>
You've misunderstood the idea. Standard library functions classes etc. are
not language features.
It's not a purpose of this RFC to move existing functions from the standard
library but to allow core language features
to use it. Described examples show benefit in use for symbols tightly
coupled to features PHP as a language delivers.

Most of the standard library function can be replaced by implementations in
PHP or by wrapping around a C library.
The features tightly coupled with the language is for eg. the Reflection
mechanism, PhpToken class as described.
Upcoming PhpAttributes for which proposal is a work in progress.

Those all features will not likely be moved to PECL and this RFC proposal
is to allow features like that to use PHP namespace.

Cheers,
Michał Brzuchalski

[PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core

[Michał Brzuchalski]

Hi internals,

I hope you're doing well.

I'd like to announce the PHP Namespace in core RFC for discussion.
The RFC is authored by me together with George Peter Banyard and it's
purpose
is nothing more like to allow the use of PHP Namespace in the core.

The RFC is described at https://wiki.php.net/rfc/php-namespace-in-core

Best Regards,
Michał Brzuchalski

Re: [PHP-DEV] [VOTE] Userspace operator overloading

[Michał Brzuchalski]

pon., 23 mar 2020 o 18:58  napisał(a):

> Hi internals,
>
> I have opened voting on
> https://wiki.php.net/rfc/userspace_operator_overloading, which allows
> users
> to overload operators in their own classes.
>

I got two comments, a little late but always better than even later.

The first thing is for operator methods when the operation is not supported
I would see simply `return null;` as the right solution
instead of constant, which name no one will remember.

The second thing is notices which are confusing when suggesting to go
and implement overloaded operator method on extension derived classes
like stdClass like below:

Notice: You have to implement the __add function in class stdClass to use
this operator with an object in...

The text of the notice is not documented in the RFC but it is implemented
that way in the patch.
A PHP developer is not likely gonna download the php-src source code,
build environment and go with the ext/standard implementation and start
adding it in C.
The notice in this cases should either be different or not emitted at all.
If the latter then that has to be documented I guess.

Cheers,
--
Michał Brzuchalski

Re: [PHP-DEV] [RFC] Constructor Property Promotion

[Michał Brzuchalski]

czw., 26 mar 2020 o 14:31 Nikita Popov  napisał(a):

> Hi internals,
>
> I would like to submit the following RFC for your consideration:
> https://wiki.php.net/rfc/constructor_promotion
>
> This is based on one off the suggestions made in
> https://externals.io/message/109220, and some existing discussion on the
> topic can be found in that thread.
>
>
As I already said in linked topic. IMHO this is wrong and can be easily
overused.

A list of properties is changed into a list of constructor method arguments
which
can be easily overused on long argument lists and when the time comes to
have attributes then the list of promoted arguments with their annotations
and some extra blank lines then to improve readability could lead to
long constructor signature list on a different level of indentation which
also then always has to be un-collapsed in IDE and on the top of a class to
keep the track of properties where usually list of properties exists with
additional named constructors (always at the top).

Not even mentioning that mix of promoted and un-promoted argument list
would just feel awkward and that kind of mixed constructor where some of
arguments are assigned magically and some of them not can make it harder to
read.

And I'm not saying this cause I'm preparing another proposal for filling
the gap
between the use of ad-hoc array structures, and the use of well-defined and
type-safe value types.
I'm saying this because PHP was always verbose and easy to read/decipher
this solution IMHO has more drawbacks regarding readability than benefits.

Cheers,
--
Michał Brzuchalski

Re: [PHP-DEV] [RFC] switch expression

[Michał Brzuchalski]

arrow functions:
>
>
>
> ```php
>
> $x = fn() => {
>
>     foo();
>
> bar();
>
> baz()
>
> };
>
> ```
>
>
>
> This would, however, make it inconsistent with closures as they use the
> return keyword. Thus we would probably have to make sure arrow functions
> still work with return statement which would decrease the need for such a
> language construct. It is also very unlike anything else in PHP.
>
>
>
> # Poll
>
>
>
> This is a short overview of what I'll be working on in the coming weeks. I
> created a short poll for you guys to let me know if this idea is worth
> pursuing:
>
> https://forms.gle/stXMv72CAaDDxfwf8
>
>
>
> Stay safe!
>
>
That looks like what I've described a few months ago in
https://wiki.php.net/rfc/switch-expression-and-statement-improvement
If you dig into the mailing list you can even find almost ready to use
patch which implements it.

I'd love switch expression inclusion in PHP.

Cheers,
Michał Brzuchalski

Re: [PHP-DEV] Improving PHP's Object Egonomics: A broad analysis

[Michał Brzuchalski]

Hi Larry,

pon., 23 mar 2020 o 20:04 Larry Garfield 
napisał(a):

> Merging some replies together here...
>
> On Sun, Mar 22, 2020, at 8:36 PM, Levi Morrison via internals wrote:
> > > In short: I believe our biggest potential win is to focus on 3 RFCs:
> > >
> > > * Constructor Promotion
> > I would vote yes on this, assuming the implementation is sane.
>
> On Mon, Mar 23, 2020, at 12:55 AM, Michał Brzuchalski wrote:
>
> > That still doesn't resolve issue with lot of boilerplate when you deal
> with
> > small objects for which public readonly is enough like object-initializer
> > could. So I'm not sure about my vote here. It does solve only one narrow
> > situation for me.
>
> The value here is combining constructor promotion with named parameters.
> Constructor promotion itself is useful for the class implementer, but
> doesn't help the caller.  Named parameters helps the caller, but doesn't
> really help the class implementer.  The combination of both of them
> together gives us something similar to the object-initializer syntax as a
> net result, but with many other benefits because it's not a one-off syntax.
>
> So with the two of them together, you get:
>
> class Point {
>   public function __construct({public int $x, public int $y});
> }
>
> Which then allows any of these construction mechanisms:
>
> $p1 = new Point(5, 7);
> $p2 = new Point({x: 5, y: 7});
> $p3 = new Point({y: 7, x: 5});
>
> All of which result in an object you can use the same way:
>
> print $p1->x . ', '.  $p1->y;
>
>
I agree it looks a little bit awkward and differs from object-initializers
known from other languages,
but let's say it would work somehow for this example. Now make it not 2 but
10-15 properties
with real types sometimes quite long so after 3-5 of them you should break
the line,
then add some default values.
Like a real entity which with typed properties doesn't need setters and
getters.

The example grows but even when breaking a line after each
parameter/property still could be somehow readable.

Now as we deal with Entity add some annotations or let's go hype, try with
new Attributes v2
proposed by Benjamin Eberlei
https://wiki.php.net/rfc/attributes_v2#userland_use-casemigrating_doctrine_annotations_from_docblocks_to_attributes
3 for $id and for the rest at least one attribute per property.

class Product {
public function __construct({
<>
<>
<>
public int $id,

< true])>>
public string $name,

<>
public string $description
});
}

Let's stop on 3 I think it's enough to see it's:
1. unusual to see annotations in method signature declaration
2. not readable anymore.

Now if you say it shouldn't be like that and all the properties should be
declared as normal properties,
then the constructor is not needed to simplify the declaration but still
requires a lot of boilerplate on
the caller side undoubtedly.

Do you still think object-initializer is pointless and useless and can be
replaced with
named arguments and constructor arguments promotion?

Cheers,
Michał

Re: [PHP-DEV] Improving PHP's Object Egonomics: A broad analysis

[Michał Brzuchalski]

Hi Larry,

pon., 23 mar 2020, 01:48 użytkownik Larry Garfield 
napisał:

> Hi folks.
>
> There have been a lot of RFCs and possible RFCs of late that are all
> circling around the same related problem space: Working with objects right
> now involves too much boilerplate to get things done.  As I've mentioned
> several times, I believe we need to be looking for broader solutions rather
> than narrowly-focused one-offs.
>
> To that end, I have written an extensive analysis of the problem space and
> the current and recent proposals.  I've put it on my blog rather than
> inline here because it's quite long and the blog offers better formatting.
>
> Discussion can happen here, but I'll also respond to comments there.
>
> In short: I believe our biggest potential win is to focus on 3 RFCs:
>
> * Constructor Promotion
>

That still doesn't resolve issue with lot of boilerplate when you deal with
small objects for which public readonly is enough like object-initializer
could. So I'm not sure about my vote here. It does solve only one narrow
situation for me.

* Named parameters
>

What would be nice for methods and functions. +1

* Compound Property Visibility
>

I didn't get it what benefits over property accessors it could have.


> For details, see the full writeup:
>
> https://hive.blog/php/@crell/improving-php-s-object-ergonomics
>
> Thank you for your attention.
>
> --
>   Larry Garfield
>   la...@garfieldtech.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Michał Brzuchalski]

śr., 18 mar 2020, 03:36 użytkownik Jakob Givoni  napisał:

> Thank you, Michał, for chiming in :-)
>
> On Tue, Mar 17, 2020 at 10:52 AM Michał Brzuchalski
>  wrote:
> > For object initializer, I was hoping to introduce a feature which with
> the benefits of typed properties
> > could reduce the boilerplate on initializing object and setting their
> properties in one expression.
> Exactly my motivation with COPA as well;
> - Typed properties - check,
> - Reduce boilerplate - check,
> - Initializing and setting properties in one expression - check.
>
> > With object initializer, this could be reduced to:
> >
> > $this->dispatch(new SomeCommand { foo = 'bar', baz = false });
> And with COPA it would be;
> $this->dispatch((new SomeCommand)->[ foo = 'bar', baz = false ]);
> Subtle differences, when compared to the currently available alternative.
>

The difference is in object state initialization :

Using Object Initializer enforce that if a class is instantiated with the
Object Initializer, at the end of the instantiation and properties
initialization, all visible properties *(depends on initialization scope)* are
initialized, otherwise, a RuntimeException is thrown. This helps to avoid
bugs where a property is added to the class but forgot to be assigned it a
value in all cases where the class is instantiated and initialized.
https://wiki.php.net/rfc/object-initializer#restrictions

You can't do that with COPA cause it has nothing to do with object
instantiation.



> > But as mentioned IMO this is a different feature than what you propose
> and personally I see no point
> > in reducing only assignment statements without combining it with object
> construction for these kinds
> > of small objects, DTO's, commands, queries and events.
> Maybe you missed that COPA can be combined with object construction?
>
> > but personally I don't need a constructor at all in those cases since we
> > have typed properties and it looks like they could be also marked as
> read-only in next major PHP version.
> Exactly, and as I couldn't help notice that you voted for the Write
> Once Properties RFC, which clearly states that
> object construction is a fuzzy term (meaning don't take it too
> seriously) and lazy initialization is a feature...
>
> I hope you will either reconsider your support for COPA or let me know
> what I'm missing so I can
> consider other directions.
>

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Michał Brzuchalski]

Hi Jakob,

wt., 17 mar 2020 o 03:08 Jakob Givoni  napisał(a):

> On Mon, Mar 16, 2020 at 6:48 AM Jakob Givoni  wrote:
> > Let me know what you think!
>
> Thank you for your feedback so far!
>
> I'd be really curios to know what authors of the referenced RFCs think
> about this, f.ex.
> Michał (brzuc...@php.net), Andrey (andrewg...@rambler.ru) and Nikita
> (ni...@php.net)
>
> Is simple inline object population useful in itself?
> Is the proposed implementation as trivial as I think it is?
>

For object initializer, I was hoping to introduce a feature which with the
benefits of typed properties
could reduce the boilerplate on initializing object and setting their
properties in one expression.

This is somewhat what I personally do a lot for commands and events
construction where
those simply have public typed properties and I don't care if something
would be changed
in the meantime.

With current RFC for write-once, I can see object initializer could be an
awesome feature
with a combine of read-only properties.

Currently I would have to do a lot of:

$command = new SomeCommand();
$command->foo = 'bar';
$command->baz = true

$this->dispatch($command);

For SomeCommand looking like (with read-only for example purposes)
class SomeCommand {
public readonly string $foo;
public readonly bool $baz;
}

With object initializer, this could be reduced to:

$this->dispatch(new SomeCommand { foo = 'bar', baz = false });

But as mentioned IMO this is a different feature than what you propose and
personally I see no point
in reducing only assignment statements without combining it with object
construction for these kinds
of small objects, DTO's, commands, queries and events.

And agree with others that brackets look unnatural for anything related to
objects.

IIRC there were many questions about named parameters to pass for object
constructor or proper
property setters like in C#, but personally I don't need a constructor at
all in those cases since we
have typed properties and it looks like they could be also marked as
read-only in next major PHP version.

Cheers,
--
Michał Brzuchalski

Re: [PHP-DEV] Re: [RFC] Attributes v2

[Michał Brzuchalski]

pon., 9 mar 2020 o 15:45 Benjamin Eberlei  napisał(a):

> On Mon, Mar 9, 2020 at 3:42 PM Benjamin Eberlei 
> wrote:
>
> > Hi all,
> >
> > I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in
> > 2016 with a few changes, incorporating feedback from the mailing list
> back
> > then and from talking to previous no voters.
> >
> > The RFC is at https://wiki.php.net/rfc/attributes_v2
> >
> > A working patch is at https://github.com/beberlei/php-src/pull/2 though
> > work around the details is still necessary.
> >
> > The RFC contains a section with common criticism and objections to
> > attributes, and I hope to have collected and responded to a good amount
> > already from previous discussions.
> >
> > There is also a fair amount of implementation detail still up for debate,
> > which is noted in "Open Issues". I have pre-committed to one approach,
> but
> > listed alternatives there. On these issues I am looking for your
> feedback.
> >
>
> Obviously I am looking for feedback on the whole RFC, not just the open
> issues :-)
>
> >
> > greetings
> > Benjamin
> >
>


Hi Benjamin,

I'm really glad you're taking up the baton!

IMHO a bunch of straw polls could provide a way more beneficial knowledge
about feelings
people who can vote up for this feature. What do you think?

It could be good to discover the negative or positive feelings as well as
"I'm not opposite" feelings.

>From what I can see now and I didn't think of it earlier are some details
but we should ask the question
how far we wanna go with this feature for its an initial shape.

Are we gonna provide complete attributes feature like C#, Java etc. which
allows for
annotating annotations (whatever it's called for me annotations/attributes
has no difference for now)
meaning they allow to put metadata which puts restrictions on:

1. Usage of the attribute should be allowed once or multiple times
regarding the same target?
2. Targetting attributes should be annotated - no matter if through an
interface or annotation?
3. Allow for inheritance should be annotated - meaning when reading
attributes for class Bar
  which extends Foo on which attributes are set, should I get attributes or
not?
4. Should attributes be resolvable all the time, what if the class won't
exist on runtime?
  In some languages like Java there are for eg. documentary annotations
which live with code but are not stored on runtime.

Or we simply want to provide a simple way of retrieving the metadata from
class/trait/interface/properties/methods/functions without checking their
repeateness, without inheritance,
without validating the targets where they appear, and just allow to move
any kind of attributes into
the language and allow the userland to decide what to do with them and how
to handle them properly?

The thing which I haven't consider earlier and I find it nice features is
the ability
to filter annotations against some abstract/base annotation - it may be
described as a better cause
I do feel like it should be done through extending of the interface and not
by an abstract class.
Like from the RFC itself the `\Validator\Attributes\Attribute::class` it
wouldn't make sense for it to be
a class, not even an abstract class, there's probably no method which this
abstract will provide.

Attributes should be forbidden for instantiation and this if funny cause
they do have a public __construct
so they look like classes but are not actually classes which you should be
allowed to instantiate wherever
you want, right? So we agree it looks a little weird here but dunno if
there's something we can do.

cheers,
Michał Brzuchalski

Re: [PHP-DEV] [RFC] token_get_all() TOKEN_AS_OBJECT mode

[Michał Brzuchalski]

czw., 13 lut 2020 o 10:48 Nikita Popov  napisał(a):

> Hi internals,
>
> This has been discussed a while ago already, now as a proper proposal:
> https://wiki.php.net/rfc/token_as_object
>
> tl;dr is that it allows you to get token_get_all() output as an array of
> PhpToken objects. This reduces memory usage, improves performance, makes
> code more uniform and readable... What's not to like?
>
> An open question is whether (at least to start with) PhpToken should be
> just a data container, or whether we want to add some helper methods to it.
> If this generates too much bikeshed, I'll drop methods from the proposal.
>
> Regards,
> Nikita
>

Hi Nikita,

I really like the RFC itself and got only one question regarding the class
name
which I couldn't find an answer in RFC.

Why PHP prefix in PhpToken class name?
Why can't we go with Token class name alone without the prefix?

The only one which includes PHP in class names so far are only:

* __PHP_Incomplete_Class
* php_user_filter

Above taken from https://www.php.net/manual/en/reserved.classes.php

BR,
Michał Brzuchalski

Re: [PHP-DEV] [RFC]

[Michał Brzuchalski]

wt., 11 lut 2020, 21:14 użytkownik Dik Takken 
napisał:

> On 11-02-2020 20:01, Michał Brzuchalski wrote:
> > wt., 11 lut 2020, 18:42 użytkownik Manuel Canga 
> > napisał:
> >
> > That reminds me an old draft RFC https://wiki.php.net/rfc/short-closures
> > where I thought curly braces can be used to create closure from syntax
> > nearly the same as invoking but without parentheses.
>
> My message mentioning just about the same idea crossed yours. Thanks for
> pointing at this RFC, I think it just caught our attention again. :)
>
> I quickly scanned the list to see if your RFC was discussed and all I
> could find was threads about a different RFC with almost identical name
> (https://wiki.php.net/rfc/short_closures). Has it not been discussed
> before?
>

No, it hasn't been discussed. It stopped at being a draft.

BR,
--
Michał Brzuchalski

>

Re: [PHP-DEV] [RFC]

[Michał Brzuchalski]

wt., 11 lut 2020, 20:08 użytkownik Dik Takken 
napisał:

> On 11-02-2020 17:48, Dan Ackroyd wrote:
> > I didn't include the following in that RFC, because I thought it would
> > be too controversial, but I think it's worth considering a new syntax
> > for this.
> >
> > Given the code:
> >
> > function foo();
> > class Zoq {
> > public function Fot() {}
> > public static function Pik() {}
> > }
> > $obj = new Zoq();
> >
> >
> > Then these:
> >
> > $(foo);
> > $($obj, Fot);
> > $(Zoq, Fot);
> >
> > Would be equivalent to:
> >
> > Closure::fromCallable('foo');
> > Closure::fromCallable([$obj, 'Fot']);
> > Closure::fromCallable('Zoq::Fot'); or Closure::fromCallable(['Zoq',
> 'Fot']);
> >
> > Or similar.
>
> Given the fact that $() would only accept functions and methods as
> argument, this idea could be taken one step further by writing:
>
> $(foo);
> $($obj->Fot);
> $(Zoq::Fot);
>
> Referring to a method like this is normally not possible because it is
> ambiguous. However, wrapped inside $(), which only accepts functions and
> methods, the ambiguity disappears.
>
> The $() syntax is nice and short. And something completely new. As new
> syntax can only be 'spent' once, more familiar alternatives should be
> explored as well. Thinking about the existing list() and array() syntax,
> another possibility could be:
>
> closure(foo);
> closure($obj->Fot);
> closure(Zoq::Fot);
>

It looks like a function but it's not a function cause what you have inside
parentheses looks like a const, property and class const.

IMO a statement like that for consistency it should be with no parentheses
like:

$foo = closure foo;
$foo = closure $obj->Fot;
$foo = closure Zoq::Fot;

Cheers,
--
Michał Brzuchalski

>

Re: [PHP-DEV] [RFC]

[Michał Brzuchalski]

wt., 11 lut 2020, 18:42 użytkownik Manuel Canga 
napisał:

> On Tue, 11 Feb 2020 at 17:49, Dan Ackroyd  wrote:
> >
> > Nicolas Grekas wrote:
> > > I wish this would return a Closure instead, making $foo::function the
> > > equivalent of Closure::fromCallable($foo).
> >
> > I didn't include the following in that RFC, because I thought it would
> > be too controversial, but I think it's worth considering a new syntax
> > for this.
> >
> > Given the code:
> >
> > function foo();
> > class Zoq {
> > public function Fot() {}
> > public static function Pik() {}
> > }
> > $obj = new Zoq();
> >
> >
> > Then these:
> >
> > $(foo);
> > $($obj, Fot);
> > $(Zoq, Fot);
> >
> > Would be equivalent to:
> >
> > Closure::fromCallable('foo');
> > Closure::fromCallable([$obj, 'Fot']);
> > Closure::fromCallable('Zoq::Fot'); or Closure::fromCallable(['Zoq',
> 'Fot']);
> >
> > Or similar.
> >
> > The justification for having a dedicated syntax is that I think
> > readability is quite important in code, and it's reasonably common for
> > me to have quite long lists of 'callables'.
> >
> > [Bar::class, foo1::function],
> > [Bar::class, foo2::function],
> > [Bar::class, foo3::function],
> > [Bar::class, foo4::function]
> >
> > vs
> >
> > $(Bar, foo1),
> > $(Bar, foo2),
> > $(Bar, foo3),
> > $(Bar, foo4)
> >
> > The latter is far easier to read for me.
> >
> > Nikita Popov wrote:
> > > This would circumvent all the issues outlined in
> > > https://wiki.php.net/rfc/consistent_callables.
> >
> > Probably there would still be some issues with some of the weird stuff
> > happening internally in SPL related code where the deep horrors
> > rest...but we can leave them alone...and they might not wake.
> >
> > cheers
> > Dan
> > Ack
>
> Other option:
>
> Closure::fromCallable('foo');
> Closure::fromCallable([$obj, 'Fot']);
> Closure::fromCallable('Zoq::Fot'); or Closure::fromCallable(['Zoq',
> 'Fot']);
>
> to
>
> 
> <$foo, Fot>
> 
> 
>
> E.g:
>
> array_map(, $array);
> array_map(, $array);
>
> Do you like ?
>

That reminds me an old draft RFC https://wiki.php.net/rfc/short-closures
where I thought curly braces can be used to create closure from syntax
nearly the same as invoking but without parentheses.

That way we can provide clear intent - I mean if whatever is around: curly
braces or $ with parentheses IMHO it should be consistent with call like
format. For example:

$(strlen) or {strlen} for Closure::fromCallable('foo')

$($foo->Fot) or {$foo->Fot} for Closure::fromCallable([$obj, 'Fot'])

$(Zoq::Fot) or {Zoq::Fot} for Closure::fromCallable('Zoq::Fot')

Etc. The same inside like a call but wrapped in something and with no
parentheses part.

Cheers,
--
Michał Brzuchalski

>

Re: [PHP-DEV] [RFC] Adding a "Stringable" interface to PHP 8

[Michał Brzuchalski]

wt., 11 lut 2020 o 13:59 Guilliam Xavier 
napisał(a):

> On Tue, Feb 11, 2020 at 1:12 PM Nicolas Grekas
>  wrote:
> >
> > >
> > > Just so someone has mentioned it... is "Stringable" really the best
> name
> > > for this interface? Reddit really didn't like it ;) Some possible
> > > alternatives: ToString, HasToString, CastsToString.
> > >
> >
> > Naming things...
> > I'm not sure reddit is the way to lobby php-internals...
> > I proposed Stringable because it is the most consistent to me:
> > Traversable, Serializable, Countable, Throwable, JsonSerializable
> > all are related to some special engine behavior, which this ones also is.
>
> But one could argue that "string" is not a verb like "traverse",
> "serialize", "count", "throw" etc.
> Potential alternatives would be Stringifyable (or Stringifiable?),
> StringCastable, StringConvertible...
> (Even though I personally have no problem with "Stringable")
>
>
Maybe StringObject? We do already have ArrayObject.

BR,
--
Michał Brzuchalski

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Michał Brzuchalski]

Hi Paul,

thanks for bringing it back. Got some questions:

1. In your RFC $_ENV is bound to $request.

Looking at HttpFoundation can see it's build from $_GET, $_POST, $_FILES,
$_COOKIE, $_SESSION
and then looking at PSR ServerSideRequest it's build from $_COOKIE, $_GET,
$_POST, $_FILES, $_SERVER
but none of them bounds $_ENV.

Server environment variables basically don't change over time when server
process runs.
What is the specific use case that requires them to be coupled with
$request instance?

2. In your RFC all headers are mapped to $request properties

This behaviour is unclear and unusual to me, for eg. in summary can see
that if
server request has "Header-Name" it is found in
$_SERVER["HTTP_HEADER_NAME"] and
that one is bound to $request->headers["header-name"], ok but the next line
with example for
"Content-Type" shows that it's bound to $request->contentType - which means
probably that it can
be accessed in $request->headers["content-type"] as well, right? seems
logic.

Going further, for eg. $_SERVER["PHP_AUTH_PW"] is bound to $request->authPw
and then
what will happen if the request will receive "Auth-Pw" header?

a) It'll be bound to $request->headers["auth-pw"] ?

b) It'll be bound to $request->authPw ?

c) None of above.

With those above I would see a set of getters like getContentType() or
getAuthPassword() etc.
instead of ServerRequest instance properties and a single point to retrieve
header values just like
well known ParameterBag's from HttpFoundation to operate on get, post,
headers etc.

BR,
--
Michał Brzuchalski

Re: [PHP-DEV] Allowing variable strings to be defined for a string offset

[Michał Brzuchalski]

pon., 16 gru 2019 o 10:58 George Peter Banyard  napisał(a):

> Greetings internals,
>
> I'm here to get internals's opinion about allowing a string offset to be
> replaced with arbitrary strings.
>
> Since forever strings with more then one byte have been truncated silently
> to one byte. The case with empty string *kinda* was existent but had a
> buggy behaviour (see bug 71572 [1]) and as such has been turned into a
> warning in PHP 7.1.0, and is meant to be promoted to an Error Exception per
> the Reclassifying engine warnings RFC. [2]
> An illustration of both these cases is available on 3v4l.org [3]
> <https://3v4l.org/O0nEM>
>
> I've got an implementation ready as a pull request on GitHub [4] (which
> still needs some polishing for it to make CI happy and fix the various
> leaks).
>
> However, the question is if this behaviour is desirable. Moreover, the
> silent truncation of strings with more than one byte should be changed to
> the same severity as the empty string case; i.e. an Error Exception. This
> seems reasonable due to the possible loss of data.
>
> What ever the decision is, a BC break is to be expected. As code which
> inadvertently tries to assign multiple bytes to an offset will know have
> all those bytes in the string whereas before only the first one was used to
> replace the byte at the designated offset. On the other hand the
> introduction of an Error Exception is obviously a BC break but as it points
> out to some kind of logic error.
> I would assume the impact to be minimal for both of these case.
>
> Any opinions?
>
> Best regards
>
> George Peter Banyard
>
> [1] https://bugs.php.net/bug.php?id=71572
> [2] https://wiki.php.net/rfc/engine_warnings
> [3] https://3v4l.org/O0nEM
> [4] https://github.com/php/php-src/pull/5013


Allowing to unset string offset with empty string assignment in your patch
will not trigger a Warning anymore,
but using unset with string offset currently emits "Fatal error: Uncaught
Error: Cannot unset string offset".
An expected result is to be the same but an effect radically different as
you can see [1].

IMHO allowing string offset to be unset using unset construct could be
allowed to ensure consistency then.

Any thoughts on this?

BR,
--
Michał Brzuchalski

[1] https://3v4l.org/0Ol3N

Re: [PHP-DEV] Concept: "arrayable" pseudo type and \Arrayable interface

[Michał Brzuchalski]

pon., 18 lis 2019 o 09:39 Peter Bowyer 
napisał(a):

> On Sun, 17 Nov 2019 at 23:44, Ben Ramsey  wrote:
>
> >
> > > On Nov 17, 2019, at 17:28, Mike Schinkel  wrote:
> > >
> > > If we are going to open up arrays for enhancement in PHP 8 I would ask
> > that we seriously consider addressing the various differences between a
> > built-in array and an instance of ArrayObject and/or the related
> associated
> > interfaces such that the objects can be used interchangeably with a
> > built-in array
> >
> > I completely agree. I would love to see anything implementing ArrayAccess
> > able to be used in any of the array functions.
> >
> > This might be a way-out-in-left-field concept, but if we went down this
> > path, perhaps a PHP array could become an object internally (i.e.,
> > ArrayObject) without changing the way it works in existing code? Then,
> > if/when generics are introduced, a PHP array would already be a class to
> > which a generic type parameter could be applied.
>
>
> I agree with Mike & Ben. Another voice in support of this.
>

IMO there is a little catch, at least one.

Currently, arrays all together with rest of scalar types are value-types
which means when they're passed on (unless passed by a reference) their
copies are modified but not the original one.
That's cause object's in PHP are reference types, when passed they're
always passed by reference.
Thus making a general ArrayObject class even internally for now should
follow value-types semantics.
How do you want to reconcile that?

Another thing is when shaping an OO API on general array class ->
ArrayObject all of the existing array_xxx
functions IMO should be deprecated and that's not likely gonna happen.

If you ask me why I think like that, well if ArrayObject is going to be
automatically served from all arrays
keeping array_xxx functions makes no longer a sense, the only thing they
could do from that point
is only calling an ArrayObject method, which is different from what they do
now they return a new value-type
a new array with filtered, mapped key-value array elements, when working
with objects you expect
them to mutate themself if they're mutable or return a brand new instance
when they're immutable.

Going further if ArrayObject is gonna have for eg. map() method it should
return a new instance of self
with different key-value pairs collection - this means ArrayObject has to
know how to create a new self.
This is easy for built-in class but when you go to polymorphism and would
like to extend it in MyFooArray
you need to implement map method as well cause maybe there is an additional
initialization needed
besides of key-value pairs only, for eg. additional constructor argument.
If that happens for internal array_xxx functions it would be hard to guess
how to create a new instance,
they'd become a thin wrapper of calling ArrayObject like methods, nothing
more.

TBH, in general, I think I wouldn't mess up anything. iterable is a pseudo
type cause there were reasons for that.
iterable accepts arrays, objects implementing iterator or generator.
iterable doesn't mean all that accepts is countable (look at generators).
speaking of arrayable probably you're thinking of counting it too, but then
it would require to behave like an intersection of types
arrayable = iterable - going further it would not accept
generators anymore - concluding people would still use iterable
and not arrayable for traversing using foreach etc.

Just my 50cents.

Cheers,
Michał Brzuchalski

[PHP-DEV] Re: [VOTE] Object Initializer

[Michał Brzuchalski]

Hi all,

I've closed the vote. Object Initializer RFC failed with 26 votes against
and only 3 in favour.
The second vote has a meaning only for future revive of this feature.
The majority decided that the preferred assign token should be eq "=".

Thanks to all for taking a vote.

Cheers,
Michał Brzuchalski

pon., 7 paź 2019 o 13:00 Michał Brzuchalski 
napisał(a):

> Hi all,
>
> the discussion period was long and discussion I think quite comprehensive.
>
> The RFC is at https://wiki.php.net/rfc/object-initializer and is up for
> voting now.
> The voting will take 2 weeks from 11:00 UTC 7th till 11:00 UTC 21st of
> October 2019.
>
> BR,
> Michał Brzuchalski
>

Re: [PHP-DEV] Inline switch as alternative to nested inline conditional

[Michał Brzuchalski]

Hi Kosit,

śr., 16 paź 2019 o 09:41 Kosit Supanyo  napisał(a):

> Hi Michal
>
> I'had the idea similar to your RFC but instead of using `switch` keyword I
> think introducing `when` keyword is better. (as I know a language that uses
> this keyword is Kotlin)
>
> $result = when ($v) {
> 'foo' => 1,
> 'bar' => 2,
> 'x', 'y', 'z' => 3,
> default => null,
> };
>
> Above you can see that `when` syntax is more semantic than `switch`. And
> it is easier to implement in parser because it has no statement/expression
> ambiguity.
>
> But this might not be preferred by BC camps because introducing a new
> keyword might break BC.
> And if `switch` is chosen I still think the syntax should be comma
> separated instead of semicolon separated for consistency with other list
> expressions (array/function call).
>
> $result = switch ($v) {
> case 'foo' => 1,
> case 'bar' => 2,
> case 'x', 'y', 'x' => 3,
> default => null,
> };
>

That's exactly my proposal with commas, see here:
https://wiki.php.net/rfc/switch-expression-and-statement-improvement#switch_expression_introduction
Unfortunately, this RFC needs more work cause it mixes switch statement
enhancement with comma-separated list syntax and of switch statement - I
need to split it into two RFC's

This is nice hearing that this idea has an interest.
As soon as the RFC will be split and finished I can start a discussion
thread.

Cheers,
Michał Brzuchalski

Re: [PHP-DEV] Inline switch as alternative to nested inline conditional

[Michał Brzuchalski]

Hi David,

I'm interested in this feature this is called switch expression and is on
my list of RFC to process after Object Initializer RFC.

I have an RFC in draft for that and planning to finish it soon together
with some syntax optimisations - you can see it at
https://wiki.php.net/rfc/switch-expression-and-statement-improvement

Cheers,
Michał Brzuchalski

śr., 16 paź 2019, 03:46 użytkownik David Rodrigues 
napisał:

> Hello. I like to suggests a discussion about a FR to make possible to
> inline switch, as an alternative to nested inline conditionals.
>
> $value = switch (expr()) {
> case A1: return A2;
> case B1: return B2;
> default: return C;
> }
>
> Instead of:
>
> $expr = expr();
> $value = $expr == A1 ? A2 : ( $expr == B1 ? B2 : C );
>
> Just a discussion to check what do you think.
>
> --
> David Rodrigues
>

Re: [PHP-DEV] Re: [VOTE] Object Initializer

[Michał Brzuchalski]

Hi Marco,

pon., 7 paź 2019 o 13:24 Marco Pivetta  napisał(a):

> Hey Michal,
>
> Overall, I like the idea of simplifying constructors. I downvoted the RFC
> because:
>
>  * I don't like/want co-existence of ctor and initializer
>  * `__set` interactions seem to also be a lot of non-trivial added
> complexity.
>
> If this was a short-hand for a constructor replacement (exposed in the same
> way downstream and in reflection) I'd totally be for it, but as it is it
> blurs the entire class definition by a lot, making things very difficult to
> anything reflection-ish based.
>

Thank you for your feedback.

Cheers,
Michał Brzuchalski

[PHP-DEV] Re: [VOTE] Object Initializer

[Michał Brzuchalski]

Hi all,

A follow-up note.
There is no implementation of a patch yet.

BR,
Michał Brzuchalski

pon., 7 paź 2019 o 13:00 Michał Brzuchalski 
napisał(a):

> Hi all,
>
> the discussion period was long and discussion I think quite comprehensive.
>
> The RFC is at https://wiki.php.net/rfc/object-initializer and is up for
> voting now.
> The voting will take 2 weeks from 11:00 UTC 7th till 11:00 UTC 21st of
> October 2019.
>
> BR,
> Michał Brzuchalski
>


-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

[PHP-DEV] [VOTE] Object Initializer

[Michał Brzuchalski]

Hi all,

the discussion period was long and discussion I think quite comprehensive.

The RFC is at https://wiki.php.net/rfc/object-initializer and is up for
voting now.
The voting will take 2 weeks from 11:00 UTC 7th till 11:00 UTC 21st of
October 2019.

BR,
Michał Brzuchalski

[PHP-DEV] Re: [RFC] Object Initializer

[Michał Brzuchalski]

Hi all,

the discussion period was long and discussion I think quite comprehensive.

I'd like to open the RFC up for a voting today at 11:00 UTC. The voting
will take from 11:00 UTC 7th till 11:00 UTC 21st of October 2019.

BR,
Michał Brzuchalski

czw., 12 wrz 2019 o 16:00 Michał Brzuchalski 
napisał(a):

> Hi internals,
>
> I'd like to open discussion about RFC: Object Initializer.
>
> This proposal reduces boilerplate of object instantiation and properties
> initialization in case of classes without required constructor arguments as
> a single expression with initializer block.
>
> https://wiki.php.net/rfc/object-initializer
>
> I appreciate any feedback you all can provide.
>
> Thanks,
> --
> Michał Brzuchalski
> brzuc...@php.net
>

Re: [PHP-DEV] [RFC] Object Initializer

[Michał Brzuchalski]

Hi Arvids,

sorry for the late response, I've been busy recently.

wt., 17 wrz 2019 o 13:08 Arvids Godjuks 
napisał(a):

>
> I've have been keeping up with the thread and at this point, I do somewhat
> agree with people that maybe the RFC should go into V2 version development.
> It really seems like the scope of the RFC is just too small for the feature
> and it might be a good idea to expand it a bit.
>

I'm gonna let it go as it currently is, there's still time before PHP 8.0
for improvements.
IMO with all the goods like list of properties to set and restriction which
forces to properly initialize object instance with all required fields is
enough.


> Also, I have this question - is there any performance to be gained here?
> Cause right now object hydration is an issue and is somewhat slow. Can it
> be optimised?
> Also, usually I don't really want properties to be public (aka writeable),
> so that means `private/protected` and I need to use the methods to set the
> properties or reflection. I might have missed or don't remember it, but I
> don't think I saw a discussion about that use-case. Value object, DTO's -
> all have a big use case for it.
>

This feature has no implementation yet so won't speak out about performance
and optimisation now.
Declaring classes with private/protected fields doesn't mean you cannot to
object initialization using object initializer, you can do this from class
inner scope exactly the same way as you're able to access them from class
inner scope now.
This feature may not be a cure for all diseases, but I believe is the right
to reduce noise and boilerplate when instantiating and initializing simple
objects with type restrictions and ensures valid object state every time
it's used.

BR,
Michał Brzuchalski

Re: [PHP-DEV] Re: [RFC] Object Initializer

[Michał Brzuchalski]

Hi Rowan,

pon., 16 wrz 2019 o 16:57 Rowan Tommins 
napisał(a):

>
>
>>
>>>
>>> That would require multiple new features, though, so initializers might
>>> be
>>> more achievable in the short term, and perhaps there is room for both,
>>> particularly if support for getters and setters improves.
>>>
>>>
>> Here again, IIRC you're trying to solve the issue which is off-topic.
>> Improving protected and private properties initialization through
>> constructor is not the main target of current RFC.
>>
>
>
>
> I don't think it's off-topic to consider whether a related feature would
> make this one redundant. However, you've picked a weird sentence to reply
> to, because I'm agreeing with you, that the two features could exist side
> by side without being redundant.
>

Sorry for that, the quoted sentence was left unintentionally and yes, it's
not off-topic.
Had to rethink what I was trying to say, but I do think both these features
could exist.

Regards,
Michał Brzuchalski

Re: [PHP-DEV] Re: [RFC] Object Initializer

[Michał Brzuchalski]

Hi Rowan,

pon., 16 wrz 2019 o 15:47 Rowan Tommins 
napisał(a):

> On Mon, 16 Sep 2019 at 08:29, Michał Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
> > Please keep in mind that initializing properties through object
> initializer
> > applies to visible properties and is possible to assign
> > protected or private properties from the class scope as well.
> >
>
>
> The problem with that is that you need an extra static method to make use
> of it, and you still need to get the arguments into that method. It might
> be useful occasionally, but it still doesn't help constructors which are
> setting a large number of private / protected properties.
>
>
This RFC is not trying to help those constructors but tries to simplify
instantiation objects and initializing properties
there where any kind of constructor won't help, but rather would be
unnecessary at all.

The proposed solution applies well in DTO, "structs" etc. where you need to
deal with 15+ properties which
don't need any other validation than types and those are completely valid
uses of public properties.


>
> > I don't see the reasons why many of you consider public properties a bad
> > solution. PHP language has support for public properties
> > and with typed properties, it is possible to ensure valid object state
> > using VO's which are valid all the time, consider Uuid userland
> > implementation
> > no one checks if that's valid UUID, cause it's ensured by VO.
> >
>
>
> Firstly, it's not necessarily a case of "considering public properties a
> bad solution"; it's about evaluating where the new feature could be used,
> and where it wouldn't help. If there was a feature which helped this use
> case *and* other use cases, I think that would be "better", but that
> doesn't make this feature "bad".
>
> Secondly, typed properties certainly make public properties more appealing,
> but there are still a bunch of things that you can't do with them, like
> declaring them readonly, or having logic other than type validation in
> getters and setters. Note that C#, which has object initializers, also has
> these features, making them a lot more powerful.
>
>
True, C# which ships with object initializers also having property
accessors, read-only etc.
There are RFC's treating about named arguments, property accessors showing
up occasionally on ML.
But none of them was accepted.
This is another feature and another talk. There is no RFC's which tries to
solve all those issues
in one big RFC, as such chances of success would be very low.


>
> > Any kind of features like promoting arguments from the constructor or
> named
> > arguments are fine but not efficient in those cases.
> > Any good practices suggest limiting function|method arguments while the
> > case is where there is a significant amount of properties
> > to be initialized and additionally which don't need any kind of
> validation
> > due to VO, or simple scalars.
> >
>
>
>
> That's a good point; named parameters make function calls scale much better
> to long lists of parameters, but *declaring* the constructor would still be
> unwieldy. The only way to improve that would be for the class to
> effectively opt into having an initializer using a special syntax for the
> constructor. Larry gave this example syntax:
>
>
Please define long lists of parameters, cause issue this RFC is trying to
solve is a simplification
and ensuring properly initialized state of all required and visible
properties and we talk here
about DTO's like classes with tons of properties.

You wouldn't want to put 15+ arguments in your constructor to initialize
public properties which
don't need other validation than proper type, right?

Even if it would be just adding "public" keyword in front of them.


> class Employee {
>   protected int $age;
>   protected string $name;
>   protected ?Employee $boss;
>
>   public function hoist __construct() {
> if ($age < 18) throw new ChildLaborException();
>   }
> }
>
> And Paul M Jones mentioned this version from Hack, where the parameters are
> listed in the constructor, but don't need to be re-listed outside it:
>
> class Employee {
>  public function __construct(
> protected int $age,
> protected string $name,
> protected ?Employee $boss
>   ) {
> if ($age < 18) throw new ChildLaborException();
>   }
> }
>
>
> Either of those, with named parameters, would be almost indistinguishable
> from object initializers at the call site. Depending on the syntax chosen,
> it might be as similar as:
>
> // Call initializer, requires public properties
> new Employee { age => 42, name => 

[PHP-DEV] Re: [RFC] Object Initializer

[Michał Brzuchalski]

Hi all,

czw., 12 wrz 2019 o 16:00 Michał Brzuchalski 
napisał(a):

> Hi internals,
>
> I'd like to open discussion about RFC: Object Initializer.
>
> This proposal reduces boilerplate of object instantiation and properties
> initialization in case of classes without required constructor arguments as
> a single expression with initializer block.
>
> https://wiki.php.net/rfc/object-initializer
>

I'll try to refer to comments proposing other solutions which pop up on
this thread in one.
Suggested solutions which appeared were:
* constructor argument promotion
* named arguments

While I see them useful in general I don't see them efficient in this
specific case.
They are not competing features and could live together better suited to
different situations.
Please be the author for such RFC, I'm looking forward to that.

This RFC tries to solve a lot of noise caused by constantly repeating
$object-> when assigning properties.
Please keep in mind that initializing properties through object initializer
applies to visible properties and is possible to assign
protected or private properties from the class scope as well.
Current RFC was meant to reduce boilerplate especially on DTO|Model classes
mimicking "structs" or "data classes" empowering all goods from
typed properties.

I don't see the reasons why many of you consider public properties a bad
solution. PHP language has support for public properties
and with typed properties, it is possible to ensure valid object state
using VO's which are valid all the time, consider Uuid userland
implementation
no one checks if that's valid UUID, cause it's ensured by VO.

Any kind of features like promoting arguments from the constructor or named
arguments are fine but not efficient in those cases.
Any good practices suggest limiting function|method arguments while the
case is where there is a significant amount of properties
to be initialized and additionally which don't need any kind of validation
due to VO, or simple scalars.

There were also some positive appealing comments, especially like feedback
from Benjamin Eberlei.

> Using the object initializer would leave the object in a fully consistent
state:

I am asking myself why didn't include it yet in my RFC. Thank you for the
suggestion.
I decided to add to proposed RFC that using Object Initializer enforce that
if a class is instantiated with the Object Initializer,
then at end of the instantiation and properties initialization, all visible
(depends on initialization scope) properties are initialized, otherwise a
RuntimeException is thrown.
This could help with bugs where you add a property to the class, but forget
to assign it in all cases where the class is instantiated and initialized.

This is described under separate section
https://wiki.php.net/rfc/object-initializer#restrictions and mentioned in
https://wiki.php.net/rfc/object-initializer#introduction

> You should add mention how the Reflection API changes. I would assume
both ReflectionClass and ReflectionObject get a new method
newInstanceFields(array $fields) with the following behavior:
>
> $reflectionClass = new ReflectionClass(Customer::class);
> $customer = $reflectionClass->newInstanceFields(['name' => 'Bert']);
> // the same as
> $customer = new Customer {name = 'Bert'};

Done. Added in separate section
https://wiki.php.net/rfc/object-initializer#reflection

To all who considered this RFC missing some benefit, please try to find it
in added restriction which likely would help to avoid bugs with
uninitialized properties.

To all who didn't like the syntax. I can see arguments in favour of the use
of "=>" instead of "=" in initializer block syntax,
and would like to propose an additional vote which will help to decide
which form fits best.

Thanks in advance,
Michał Brzuchalski

Re: [PHP-DEV] [RFC] Object Initializer

[Michał Brzuchalski]

Hi Paul,

niedz., 15 wrz 2019 o 15:48 Paul M. Jones  napisał(a):

>
>
> > On Sep 12, 2019, at 09:00, Michał Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
> >
> > Hi internals,
> >
> > I'd like to open discussion about RFC: Object Initializer.
> >
> > This proposal reduces boilerplate of object instantiation and properties
> > initialization in case of classes without required constructor arguments
> as
> > a single expression with initializer block.
> >
> > https://wiki.php.net/rfc/object-initializer
>
> This reminds me of how Hack/HHVM would initialize object properties from
> constructor parameters; I remember finding it very appealing.
>
> IIRC, you would provide the property signature as a constructor parameter
> to trigger the initialization:
>
> ```php
> class Foo
> {
> protected int $bar;
>
> public function __construct(protected int $bar)
> {
> }
>
> public function getBar() : int
> {
> return $this->bar;
> }
> }
>
> $foo = new Foo(1);
> echo $foo->getBar(); // 1
> ```
>
> Perhaps something like that is worth adopting here.
>

What you're describing AFAIR was called "constructor argument promotion"
and this is not kind of problem current RFC tries to solve.
Argument promotion looks useful for constructors, in the name of good
practice constructors and methods|functions in general
should not require a lot of arguments.

Thank you for your feedback but I believe the suggested solution is
off-topic.

Thanks,
Michał Brzuchalski

Re: [PHP-DEV] [RFC] Object Initializer

[Michał Brzuchalski]

Hi Mike,

sob., 14 wrz 2019 o 10:32 Mike Schinkel  napisał(a):

>
> However, Object Initializers might be best when paired with a new magic
> method which let us call *__init(),* and a *required* modifier for
> properties.
>
> Using your Customer example, the __init() would be automatically called
> after __construct():
>
>
Thank for your feedback and ideas, but I decided not to include it in the
RFC.

Thanks in advance,
Michał Brzuchalski

Re: [PHP-DEV] [RFC] Object Initializer

[Michał Brzuchalski]

Hi Sebastian,

sob., 14 wrz 2019 o 11:05 Sebastian Bergmann  napisał(a):

> Am 13.09.2019 um 15:23 schrieb Matthew Brown:
> > Though this is truly a stylistic complaint, I think it will lead to
> > harder-to-analyse code.
>
> Fully agreed, and not just harder-to-analyse for a static analysis tool
> but also for humans that read the code. -1 from me.
>
>
Could you explain why additional noise caused by constantly repeating
instance variable name and arrow in front of property name and assignment
part
is easier to read? Just wondering why you see object initializer as harder
to read which I've view as easier to read.

Example - easy to read:
function createCustomerDTO(): Customer
{
$customer = new Customer();
$customer->id = Uuid::uuid4;
$customer->name = "John Doe";
$customer->address = "Customer Street 16";
$customer->city = "London";
$customer->country = "GB";
$customer->phoneNumber = PhoneNumber::fromString("+1555 010 020");
$customer->birthDate = new DateTimeImmutable("1983-01-01");
$customer->email = Email::fromString("john@example.com");

return $customer;
}

Example - hard to read: Why?
function createCustomerDTO(): Customer
{
return new Customer {
id = Uuid::uuid4,
name = "John Doe",
address = "Customer Street 16",
city = "London",
country = "GB",
phoneNumber = PhoneNumber::fromString("+1555 010 020"),
birthDate = new DateTimeImmutable("1983-01-01"),
email = Email::fromString("john@example.com"),
};
}

Thanks in advance,
Michał Brzuchalski

Re: [PHP-DEV] [RFC] Object Initializer

[Michał Brzuchalski]

pt., 13 wrz 2019 o 11:29 Mike Schinkel  napisał(a):

> IMO should stay specific for arrays only.
>
>
> Why?  Is there an objective reason?
>
>
$obj->foo => 123;
Simply, that's not the way you initialize object property values.

When you use "=>" in array context you're pushing a new value to array and
it'll work without labelling it with key
where the key could be number index or string index in what shape you want
(whitespaces etc.).


> Is there some aspect of the syntax that makes it appropriate for arrays
> but inappropriate for object initialization?
>
>
>  These are honest question.
>
>
> My two cents: I would like to type less too, but I have always assumed
> that "=>" was the PHP-ish syntax for initialization of a structure so it
> seems very appropriate to use for object initialization too.
>
>
> That said,
>
>
> 1. I don't feel strongly about iti either way,
>
> 2. Unless using "=>" would make naked object initialization possible —
> i.e. { foo => 10 } — given that it seems, as Arnold said, this would
> conflict with other meanings: { foo = 10 }
>
>
>
{ $foo = 123 }; // unexpected "}" cause of missing ";"
$bar = { $foo = 123 }; // unexpected "{" cause it's not allowed in this
context
Both examples are syntax error.
You can use {} for separating blocks of code, but now if you wanna assign
value.
Everything considered syntax error can be used for feature shaping.

Regards,
Michał Brzuchalski

Re: [PHP-DEV] [RFC] Object Initializer

[Michał Brzuchalski]

Hi Mike,

I am curious why your RFC uses "=" instead of "=>" for separating
> properties from values?
>
> If we used "=>" it is potential — with lookahead parsing — that the
> following could be unambiguous:
>
> { foo => 10 }
>
>
The reason about choosing "=" was a simplification of instantiation and
properties initialisation
and we use "=" to assign property values now.
The "=>" is specific for array key pairs and IMO should stay specific for
arrays only.

Thanks,
Michał Brzuchalski

Re: [PHP-DEV] [RFC] Object Initializer

[Michał Brzuchalski]

Hi Arnold,

pt., 13 wrz 2019 o 10:51 Arnold Daniels 
napisał(a):

> This can easily be done in a number of ways, like the suggested helper
> function. The same can be said for many other features that were
> implemented recently, like array unpacking. This feature is easy to
> implement and will make the code for data objects much more readable, with
> additional benefits for static analysis.
>
> Comments:
>
> I don't like how it works for anonymous classes. It's more difficult to
> implement since the compiler doesn't know the meaning of the (first)
> bracket. It's doesn't make the code more readable, for the same reason. I
> think it's better to not support this syntax with anonymous classes.
>
>
Probably lexical scope for anon classes would be better here, but due to
fact that proposal is to
use initializer block instead of constructor arguments, that was the reason
why initializer block
got before anon class definitions.


> The examples do not show how constructor arguments are passed. I'm assuming
> it's
>
> $customer = new Customer("foo") {
> name = "John"
> };
>
>
The examples don't show that cause it's forbidden.
There is a note on that in RFC on purpose

> Note! Object instantiation allows only constructors without required
arguments to be used.
> Any class which requires passing arguments to constructor cannot be used
in combination with object initializer.

Using constructor arguments and object initializer would introduce noise
and you'll be potentially initializing object twice:
using object initializer block and using constructor args what may be
misleading.


> About the idea of letting `{ foo = 10 }` create an `stdClass` object (not
> in the RFC); While not used much since it has no effect, it's perfectly
> okay to put your code in brackets eg `{ { { $foo = 10; } } }`. As such, I
> don't think it's a good idea to allow `new stdClass` to be omitted.
>

Future scope mentions only about letting to create stdClass with omitting
of the class name only,
nothing said about removing a new keyword.

Thanks,
Michał Brzuchalski

Re: [PHP-DEV] [RFC] Object Initializer

[Michał Brzuchalski]

Hi Claude,

pt., 13 wrz 2019 o 08:39 Claude Pache  napisał(a):

>
>
> Le 13 sept. 2019 à 07:49, Michał Brzuchalski 
> a écrit :
>
> Hi Lynn,
>
> czw., 12 wrz 2019 o 17:01 Lynn  napisał(a):
>
> Heya,
>
> What's the added benefit of this compared to implementing a constructor?
>
> The part I like is that this can be used to replace stdClass/structured
> arrays. Perhaps something like this would nice to have in PHP:
>
> ```
> $people = [];
>
> foreach ($peopleFromDatabase as [$id, $username, $name]) {
>$people[] = {
>Uuid id => $id,
>string username => $username,
>string name => $name,
>};
>// and possible automatic assignment:
>$people[] = {Uuid $id, string $username, string $name};
> }
> ```
>
>
> Removing stdClass for instantiation and initialization of simple objects is
> one of a future scope proposal.
>
> This RFC tries to address instantiation and initialization boilerplate
> reduction with a syntax which would
> not be restricted to stdClass only.
>
> Although it's not a game-changer, simple addition to the language which
> reduces boilerplate when dealing
> with objects which don't need complex constructors like for eg. DTO
> objects.
>
>
> As for `stdClass`, PHP has already a syntax:
>
> $baz = "baz";
> $obj = (object) [
> "foo" => "bar",
> $baz => true
> ];
>
> For other type of objects, that could be done with a simple helper function
>
> $customer = object_assign(new Customer, [
> "id" => 123,
> "name" => "John Doe",
> ]);
>
> where:
>
> function object_assign(object $obj, iterable $data): object {
> foreach ($data as $key => $value) {
> $obj->$key = $value;
> }
> return $obj;
> }
>
> That said, I generally use arrays rather than DTO objects or such, so that
> I can’t speak from experience.
>
> —Claude
>
>
You're of course right this can be done more or less with a helper function
which does all the required type
validation through reflection, but I believe that feature requests for
language support which reduces boilerplate
can easily spread that simplification and bring all the required type check
validations out of the box, right?

IMO the thing is as you said this would require a helper function and not
all simply like them!

Regards,
Michał Brzuchalski

Re: [PHP-DEV] [RFC] Object Initializer

[Michał Brzuchalski]

Hi Olumide,

czw., 12 wrz 2019 o 17:07 Olumide Samson  napisał(a):

> The RFC is a beautiful feature suggestion, but something is telling me as
> beautiful and straightforward the syntax is, what can the use case be?
>
> I really love Constructor or Object initialization to be implemented in
> PHP, but is there something I think you're missing in the RFC?
>
> Thanks for the RFC.
>

I'm open to suggestions.

PHP is known for borrowing features from other languages and this feature
is also known from other languages.
* Rust allows whole struct initialization in one expression, although these
are not classes but being able to instantiate, initialize
and return instance directly after it's being initialized reduces a lot of
boilerplate.
* C# uses an object initializer for the same purposes, one expression which
allows to instantiate, initialize and use the object directly after
initialization.
* Java users use hacks to do the same, even more, cause they're allowed to
call logic through method calls inside "initializer" block.

In some cases when you deal a lot with DTO objects, object instantiation
and properties initialization is very verbose and introduces a lot of noise.

class CustomerDTO {
  public Uuid $id;
  public string $name;
  public Email $email;
  public Address $address;
  public City $city;
  public Country $country;
  public PhoneNumber $phoneNumber;
  public etc...
}

Given above DTO class instantiation and initialization now requires:
* INSTANTIATE class and assign to a variable: $obj = new CustomerDTO();
* FOR EACH (can be many) needed property use the variable with object
instance and assign the property value: $obj->property = $value;

Now when you deal a lot with objects like that you can see you're
constantly repeating yourself with $obj-> part all the lines down before
you
probably would use that instance. There is no need for the constructor in
such objects, they're purpose is to transfer data between app layers.

Last months I've been working on a project which often requires to create
an entity with data decoded from JSON format, most of them had
many fields|properties required and only some of them were optional (even
those optional were nullable so possibly I could initialize them with null
once again),
so the case with which I had a lot to do was creating factories which
instantiate and for each property initialize value just to be able to
return newly created instance in the end.

That's when I thought object initializer could reduce a lot of boilerplate.
That's when I started thinking of many places where I could use that, where
my IDE could help me to write code faster without all that noise of
constantly repeating myself.

The syntax is similar to other languages.
The narrow case described in BC changes is already deprecated and in my
opinion, probably even not used or very rare.
The future scope features can potentially save even more strikes but that's
not the main reason about that RFC - nice to have but let's start with
something.

Regards,
Michał Brzuchalski

Re: [PHP-DEV] [RFC] Object Initializer

[Michał Brzuchalski]

Hi Lynn,

czw., 12 wrz 2019 o 17:01 Lynn  napisał(a):

> Heya,
>
> What's the added benefit of this compared to implementing a constructor?
>
> The part I like is that this can be used to replace stdClass/structured
> arrays. Perhaps something like this would nice to have in PHP:
>
> ```
> $people = [];
>
> foreach ($peopleFromDatabase as [$id, $username, $name]) {
> $people[] = {
> Uuid id => $id,
> string username => $username,
> string name => $name,
> };
> // and possible automatic assignment:
> $people[] = {Uuid $id, string $username, string $name};
> }
> ```
>

Removing stdClass for instantiation and initialization of simple objects is
one of a future scope proposal.

This RFC tries to address instantiation and initialization boilerplate
reduction with a syntax which would
not be restricted to stdClass only.

Although it's not a game-changer, simple addition to the language which
reduces boilerplate when dealing
with objects which don't need complex constructors like for eg. DTO objects.

Regards,
> Lynn van der Berg
>
>

Regards,
Michał Brzuchalski

[PHP-DEV] [RFC] Object Initializer

[Michał Brzuchalski]

Hi internals,

I'd like to open discussion about RFC: Object Initializer.

This proposal reduces boilerplate of object instantiation and properties
initialization in case of classes without required constructor arguments as
a single expression with initializer block.

https://wiki.php.net/rfc/object-initializer

I appreciate any feedback you all can provide.

Thanks,
--
Michał Brzuchalski
brzuc...@php.net

Re: [PHP-DEV] Silent Types

[Michał Brzuchalski]

śr., 4 wrz 2019, 05:52 użytkownik Fwentish Aelondes 
napisał:

> Hello internals,
>
> Zeev's idea to bring peace to the galaxy seems like a good idea, but
> impossible to implement in practice.
>
> But it got me thinking about how one might introduce static typing
> into a dynamically typed language w/out breaking BC.
>
> And then I had this crazy idea:
>
> //int
> $i = 0;
>
> //string
> $c = 'c';
>
> //float
> $pi = 3.14;
>
> If static typing in php was *only* an opt-in kind-of-thing, would this
> work? Could the parser be built to identify 3 or 4 different keywords
> in comments and give warnings or fatal errors for type conversions of
> variables that have the type specified in the immediately preceding
> comment?
>
> Just a (crazy) idea.
>
>  Fwentish


IMO it's crazy idea and we should not change the way comments work
especially inline comments which even aren't kept in opcache.

I think better approach would be to put type in front of first variable
declaration like:

[type] $variable = $value;


BR,
--
Michał Brzuchalski

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

śr., 14 sie 2019 o 12:17 Michał Brzuchalski 
napisał(a):

>
>
> śr., 14 sie 2019 o 12:11 Rowan Collins 
> napisał(a):
>
>> On 14/08/2019 11:07, Michał Brzuchalski wrote:
>> > Exactly so how would it know from string name either it should load
>> class
>> > from src/Foo.php or src/__nsmeta.php if there is no information?
>>
>>
>> It wouldn't. It would include src/Foo.php, and that would have the
>> definition of something with the name "Foo" - either a class, an
>> interface, a trait, or a package. If it wasn't what the engine was
>> expecting, it would be an error, just as it is right now if you write
>> "implements ClassName", or "new TraitName();"
>>
>
> Following that would introduce unneeded additional directory hierarchy
> level in a usual library
> which uses PSR-4 which is the most used one, right?
>
> /composer.json
> /src/Foo.php
> /src/Foo/ <- all package classes should go here?
>

Going even further by the example of Doctrine libraries:
# doctrine/collections - Composer Package [1]
uses PSR-4 autoload with "Doctrine\\Common\\Collections\\" prefix
to adopt package concept it would have to change the prefix to
"Doctrine\\Common\\"
to find Collections.php and all the rest of source code in Collections
directory

# doctrine/common - Composer Package [2]
uses "Doctrine\\Common\\" prefix should change into "Doctrine\\" to be able
to load
Common.php and the rest of source code in Common directory

# ocramius/package-versions - Composer Package [3]
uses "PackageVersions\\" prefix and then what?

[1] https://github.com/doctrine/collections/blob/master/composer.json
[2] https://github.com/doctrine/common/blob/master/composer.json
[3] https://github.com/Ocramius/PackageVersions/blob/master/composer.json
-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

śr., 14 sie 2019 o 12:11 Rowan Collins  napisał(a):

> On 14/08/2019 11:07, Michał Brzuchalski wrote:
> > Exactly so how would it know from string name either it should load class
> > from src/Foo.php or src/__nsmeta.php if there is no information?
>
>
> It wouldn't. It would include src/Foo.php, and that would have the
> definition of something with the name "Foo" - either a class, an
> interface, a trait, or a package. If it wasn't what the engine was
> expecting, it would be an error, just as it is right now if you write
> "implements ClassName", or "new TraitName();"
>

Following that would introduce unneeded additional directory hierarchy
level in a usual library
which uses PSR-4 which is the most used one, right?

/composer.json
/src/Foo.php
/src/Foo/ <- all package classes should go here?

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

śr., 14 sie 2019 o 11:49 Rowan Collins  napisał(a):

> > You suggest that it would trigger autoload to load "MyVendor\MyPackage"
> > but current autoload machinery is able to load only classes,
> > not even functions or consts! cause it gets the only class name now.
> > It would need to be changed anyway.
>
>
> As I said in another reply, this is only the same change that needed to
> be made to support "trait" alongside "class" and "interface", or would
> be needed to support "enum" or "struct". The userland part of the
> autoloader already doesn't know which of those it's looking for, so the
> only constraint is that the names can't collide, so you couldn't name a
> package the same thing as a class.
>
>
Exactly so how would it know from string name either it should load class
from src/Foo.php or src/__nsmeta.php if there is no information?

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

śr., 14 sie 2019 o 11:01 Rowan Collins  napisał(a):

> I don't see this as a problem. Right now, PHP doesn't care how many
> files you put your code in. As far as I know, you could concatenate the
> entirety of Laravel into one PHP file, and applications would not be
> able to tell the difference. Similarly, you could put the whole thing in
> a database and use eval() to execute it without touching any files.
>
>
That is true but not if there are any declare statements. If so it could
IMO work only like that:
 I think what attracts me to this idea is precisely that it doesn't
> require much extra machinery. We could even use the trick that PHPStorm
> uses for metadata stubs [1], and make the package definition look like
> valid executable PHP, but never actually execute it:
>
> package Foo {
>  const declare = [
> 'strict_types' => 1,
> 'strict_operators' => 1
>  ];
> }
>

How could that know when need look for package definition?
Example:

# src/Foo.php

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

Hi Rowan,

wt., 13 sie 2019 o 22:26 Rowan Collins  napisał(a):

> On 13/08/2019 18:45, Mark Randall wrote:
> > I thought about this as my first consideration, however it effectively
> > requires that the PHP code within the package class is fully parsed
> > and executed in order for it to retrieve the data.
> >
> > Consider pre-loading where the code is compiled, but not run, it would
> > not be possible to use namespace level defines to add compile-level
> > optimizations or checks (at least without some AST hackery).
>
>
> Ah, that makes sense. Does that necessarily mean we need a dummy class,
> though? The autoloading logic in the engine knows that it called the
> autoload callback expecting a package definition, so can count as
> success that the package is now defined.
>
> In other words, the file the autoloader included would look like this
> (again, sticking to the notion that "package" is separate from
> "namespace"):
>
>
> #
> # File: /lib/company/project1.php
> #
>
> 
> packagedef company/project1 {
>  strict_types=1;
>  strict_operators=1;
>  upgrade_errors_to_exceptions=E_ALL;
> }
>

Was thinking a while about proper syntax and would like to mention what I
said before.
It doesn't have to be a new syntax if we agree to put package definiction
in sort of separate configuration file.
In the end all what we need is package name and a bunch of declare
directives.
Given that it could be easily done using separate conf file like:

# package.ini
[package]
name = MyVendor\MyLibrary
strict_types = 1
encoding = UTF-8

# package.json
{
  "name": "MyVendor\\MyLibrary",
  "declare": {
"strict_types": 1,
"encoding": "UTF-8"
  }
}

# package.toml
[[package]]
name = "MyVendor\\MyLibrary"
strict_types = 1
encoding = "UTF-8"

# package.yaml
name: MyVendor\MyLibrary
strict_types: 1
encoding: UTF-8

That way it would prevent to mix normal PHP code with package definition,
cause every possible PHP syntax
we would agree, opens the door to add something more to that file, for eg.:

# package.php
https://wiki.php.net/rfc/namespace_scoped_declares#motivation_and_vision
[2] https://www.php.net/manual/en/function.register-tick-function.php
-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

Hi Larry,

pon., 12 sie 2019 o 15:45 Larry Garfield 
napisał(a):

>
> Has anyone done in-depth research into how other languages handle
> packages, and what advantages packages would have over just our existing
> nested namespaces?  I feel like there's ample prior art here that we should
> not ignore.
>

I did some writings on that
https://brzuchal.com/posts/packages-in-programming-languages/ was a little
hurry
but tried my best to grasp key aspects of package / module concept in other
languages.

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

Hi Nicolas,

pon., 12 sie 2019 o 10:17 Nicolas Grekas 
napisał(a):

> Le lun. 11 déc. 2017 à 14:44, Nikita Popov  a écrit
> :
>
> > Some time ago I introduced the following proposal for namespace-scoped
> > declares:
> >
> > https://wiki.php.net/rfc/namespace_scoped_declares
> >
> > The idea is to allow specifying declare directives for a whole library or
> > project using:
> >
> > namespace_declare('Vendor\Lib', ['strict_types' => 1]);
> >
> > I've finally gotten around to implementing this proposal (
> > https://github.com/php/php-src/pull/2972) and would like to move forward
> > with it.
> >
> > The reason why I'm picking it up again is some feedback I received for
> the
> > explicit call-time send-by-ref proposal. The main objection seems to be
> > that the feature has limited usefulness if it's optional rather than
> > required, because you still can't be sure that something is a by-value
> > pass, just because no & is present. At the same time, we can't make this
> > required anytime soon due to the large BC impact.
> >
> > Namespace-scoped declares are perfectly suited to resolve this problem.
> We
> > can introduce a require_explicit_send_by_ref declare directive to make
> the
> > call-site annotation required, and libraries/projects can easily opt-in
> to
> > it using namespace_declare(). There would be no BC impact, while at the
> > same time projects could benefit from the additional clarity and
> > performance improvements immediately.
> >
>
> I've read discussions about the notion of a "package" and the way we should
> define its boundaries.
> What about the following?
>
> Individual files could declare their package using this style:
> 
> That would be enough to group a set of files together and make them share
> eg some private classes, some optional PHP behaviors, etc.
>
>
Why suggesting use of declare for that?
Wouldn't a new "package" keyword be more appropriate for that?
For eg.:
 The right side "MyVendor\MyPackage" would also be a FQCN that PHP would
> autoload as a regular class. The corresponding class would then be the
> place where ppl would declare the engine behavior they want for their
> package (strict types, etc). To enforce this, the engine could require that
> the "MyPackage" class implements some interface/extend some base abstract
> class.
>
> Of course, one could hijack a package and declare an unrelated file as part
> of it, but I don't think that's an issue: the situation is the same as for
> namespaces, where one can hijack a third party vendor namespace. In
> practice, it proved not being an issue, and the original author's intent is
> clear: "this is my namespace/package, if you mess with it, fine, but you're
> on your own".
>
> Nicolas
>


-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Michał Brzuchalski]

Hi Zeev,

pt., 9 sie 2019, 14:23 użytkownik Zeev Suraski  napisał:

>
>
> On Fri, Aug 9, 2019 at 11:15 AM Michał Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
>> Hi Sergey,
>>
>> pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev > >
>> napisał:
>>
>> > As I understand, in P++ it was planned to drop the legacy code, add new
>> > functionality and painlessly implement BC.
>> >
>> > Who wants – migrates the PHP project in P++, who doesn't – continues to
>> > use PHP.
>> >
>> > New projects, for example, will use P++ already.
>> >
>> > Well, how is this different from the new version of PHP (e.g. PHP 9)?
>> >
>> > Who wants – adapts his code for PHP 8/9 with all its BCs, who doesn't –
>> > continued to use PHP 7/8.
>> >
>>
>> As I understand editions concept it would be far more easy to interoperate
>> with old edition written library than in separate languages like PHP and
>> P++. If new edition introduce syntax breaking change it would be still
>> possible to to interoperate with old code in old edition and work on a
>> project based on new edition.
>>
>
> If we intend to break syntax frequently, then yes.  But this is poor
> language design.
> If we take a couple of years to focus on the fundamentals of what folks
> find objectionable about PHP today, and introduce P++ with solutions to
> these issues - there's no reason that every new version continues to break
> compatibility - certainly not in a substantial manner.  We need to focus on
> the painful changes at the first stage, when P++ is introduced - while
> keeping other elements - ones which are incremental but do not introduce
> compatibility breaks - to a later time (if we don't have the
> developer-power to deliver them).
>

I've got an impression that you're the only one who sees a good direction
in splitting the language in two different dialects and am not sure about
sincere intentions.
I may be wrong about that but I read this as a way to get evolutionary camp
focus on own dialect and leave PHP in peace. But I think their interests
are in language evolution and not in writing own language.


> If we let ourselves off the hook, and do these breakages in stages -
> editions are basically a workaround.  Yes, editions would allow you to work
> around the fact that your code breaks every time you upgrade - but at a
> fundamental level, people are still wasting their time writing and
> rewriting and then rewriting once more the same code.  Not to mention that
> unless I'm missing something, maintaining the implementation for all
> different editions would be more complicated than having just two dialects.
>
> Now, it doesn't come to say that P++ will never be able to break
> compatibility.  We also break compatibility in PHP, in major versions.  But
> it does mean that something along the lines of moving from dynamic to
> static, can't happen further down the line.  Changing operator or
> type-conversion behavior - has to happen now and not further down the
> line.  Features such as union types and others - can happen at a later
> stage.  I don't think there's a need for editions for that purpose, the
> versions we have are sufficiently granular.  Even more so since this will
> likely effect P++ more frequently than PHP - a crowd which appears to have
> a much stronger bias for features than for downwards compatibility.
>
> That way you can end up on for eg PHP8 supporting edition=2020 with new
>> features which break compatibility but still working with PHP7.4 treated
>> perhaps by default as edition=2019 in future versions.
>>
>
> I could be wrong, but I don't think that even Nikita thinks we'd have a
> new edition every year.
>

That's just an example.

BR,
Michał

>

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Michał Brzuchalski]

Hi Sergey,

pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev 
napisał:

> As I understand, in P++ it was planned to drop the legacy code, add new
> functionality and painlessly implement BC.
>
> Who wants – migrates the PHP project in P++, who doesn't – continues to
> use PHP.
>
> New projects, for example, will use P++ already.
>
> Well, how is this different from the new version of PHP (e.g. PHP 9)?
>
> Who wants – adapts his code for PHP 8/9 with all its BCs, who doesn't –
> continued to use PHP 7/8.
>

As I understand editions concept it would be far more easy to interoperate
with old edition written library than in separate languages like PHP and
P++. If new edition introduce syntax breaking change it would be still
possible to to interoperate with old code in old edition and work on a
project based on new edition.

That way you can end up on for eg PHP8 supporting edition=2020 with new
features which break compatibility but still working with PHP7.4 treated
perhaps by default as edition=2019 in future versions.

Cheers,
Michał

>

Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

Hi Rowan,

wt., 30 lip 2019 o 10:48 Rowan Collins  napisał(a):

> I think there's some confusion here, because establishing the concept of a
> package as separate from a namespace is exactly what I proposed.
>
> Here's a previous message (technically in the same thread, but from 18
> months ago) where I also mentioned class visibility:
> https://externals.io/message/101323#101390
>

Was thinking about similar, a package with own identity and a way to
declare autoload and other stuff.
Was even thinking it could use a double colon which I've proposed way back
in the same thread and
with a delimiter in name all related symbols could be stored in package
individual symbol tables,
it won't collide with namespaced and global ones and would be easier to
detect if tried to use an internal symbol
in another context like other package or in global code.
It could introduce a few more keywords like:
* "package" - for declaring package name and declares,
* "export" - for explicit declare of publicly available symbols which then
could be detectable etc. for visibility features,
* "expect" - for explicit declare of required dependencies

Last two are for future features and the first one could be enough for
shaping how it could look like.
For eg. some of my thoughts
https://gist.github.com/brzuchal/c45010f0dd20642b4708b9c56c5f

I know it's out of the main topic but IMO we should start another one and
I'm pretty sure I've mentioned that earlier.
If we wanna shape package for PHP then the separate discussion could be a
good idea.

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

Hi Rowan,

niedz., 28 lip 2019 o 12:15 Rowan Collins 
napisał(a):

> 1) Packages should be non-hierarchical. Perhaps most simply a package name
> could have exactly two parts, like in composer, so it's clear that there is
> no implied relationship between two packages.
>

IMO this would create a lot of problems cause name in Composer Package
doesn't reflect used namespace declared in autoload, for eg.

Composer package name => used namespace
---
ocramius/package-version => PackageVersions\
doctrine/collections => Doctrine\Common\Collections\
symfony/console => Symfony\Component\Console\

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

Hi,

niedz., 28 lip 2019 o 05:17 Stanislav Malyshev 
napisał(a):

> > Based on the received feedback, I plan to change this proposal from being
> > "namespace-scoped" to being "directory-scoped" instead. This should both
>
> I don't think it improves much, in my opinion, and it also introduces
> hard dependency in the language on specific placing of files and
> directories - i.e. if you move file on the filesystem, it can actually
> work differently, which was never the case before. Having concepts like
> filenames change the core functionality of the language looks to me like
> an example of leaky abstraction and a hack which may solve a particular
> problem now but at the cost of making the whole design more messy and
> introducing more problems in the future.
>

IMHO it would be impossible to find out what are the boundaries of
namespace scope
or package scope (whatever you call that) symbols without a root namespace
file.

I can imagine some can use explicit require to load library class to skip
scoped declares,
autoloads or whatever lands there.

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] Object Type Casting Reloaded

[Michał Brzuchalski]

wt., 23 kwi 2019 o 11:17 Nikita Popov  napisał(a):

> ...
> Without commenting on the rest of the proposal: It's not possible to use
> (ClassName) as a cast syntax, because it is ambiguous. For example (Foo)
> [$x] is already valid syntax (fetch constant Foo and take index $x), or
> (Foo) +$bar, etc.
>

Wouldn't that be possible to differentiate consts with class names if we
merge symbol tables and allow only one symbol with the same name?

I know this is huge BC break but AFAIK in the past, there was a discussion
about merging symbol tables.

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

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

[Michał Brzuchalski]

pt., 5 kwi 2019 o 10:50 Rowan Collins  napisał(a):

>
> The original draft discussed this, but there wasn't agreement on how
> identical keys should be handled, e.g.:
>
> $a = ['foo' => 1, ...['foo' => 2]]
>
> Should $['foo'] be 1 or 2? Cases were made for both, and it was pointed out
> that if we get named arguments, the argument spread operator will need to
> work the same way as whatever is decided for arrays.
>
> So the current approach is to get integer keys working first, using the
> same behaviour as for parameters, and then revisit string keys later.
>

So we're talking about providing incomplete feature now, right?

I would opt to the same behaviour as ['foo' => 1] + ['foo' => 2] // where
'foo' key results in 1

But maybe this should be optional voting for that, either way, we're
delivering feature
which has very limited usage which can be confusing, cause I can
array_merge or
use + operator so why can't I use keys with spread operator if I already
have them in
my generator, iterable or array which came from for eg. json_decode or
whatever.

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] RFC Draft: Comprehensions

[Michał Brzuchalski]

Hi Larry,

pt., 5 kwi 2019 o 03:55 Larry Garfield  napisał(a):

>
> Advantages:
>
> * Very compact.
> * Works for both arrays and traversables
> * Would play very nicely with the proposed spread operator for iterables (
> https://wiki.php.net/rfc/spread_operator_for_array).
>

IMO not nicely cause spread operator in current proposal raises an error on
key preserved traversable[1].
This means example like below would fail

$a = ['foo' => true, ...[foreach($_GET as $key => $value) yield $key =>
$value]]; // error

[1] https://wiki.php.net/rfc/spread_operator_for_array#string_keys
-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

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

[Michał Brzuchalski]

pt., 5 kwi 2019 o 08:56 CHU Zhaowei  napisał(a):

> Here is a MDN document for spread operator in JS:
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_array_literals
> and hope you find more useful examples.
>

The next paragraph in MDN document is spread operator for object literals
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_object_literals
Now JavaScript objects can be used like our array with keys and I simply
don't understand why we cannot preserve keys, like in JS object literals

Sample code:
JavaScript: var a = {foo: true, ...{bar: "baz"}}; // become {foo: true,
bar: "baz"}
and you can access it via a.foo or as an array dimension a['foo'] - more or
less like PHP arrays, right with key as a dimenrsion in array

Your RFC covers:
PHP: $a = [1, 2, 3, ...[4, 5, 6]]; // resulting [1, 2, 3, 4, 5, 6]

What would happen in:
a) PHP: $a = ['foo' => true, ...[4, 5, 6]]; // ??
b) PHP $a = ['foo' => true, ...['bar' => 'baz']] // error ??

Don't get me wrong I just see spread operator in function arguments a
different feature which allows working with variadic parameters,
and we're talking about the different feature here which only use the same
operator, right?

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

[Michał Brzuchalski]

Hi CHU Zhaowei,

Where can I find first RFC version? Revisited RFCs AFAIK should be served
under different name.

Personally I liked key preserve behavior. Without it use of spread operator
I array expression would have minor use. But this is my personal feeling
about only.

I think I'm missing something in RFC. Usage in key preserved array
expression is not covered and the RFC doesn't describe how it would behave.

Thanks for the efforts on it

BR,
--
Michał

czw., 4 kwi 2019, 16:15 użytkownik CHU Zhaowei  napisał:

> Hi internals,
>
> Thanks for the people who joined the discussion of my [RFC: Spread
> Operator in Array Expression](
> https://wiki.php.net/rfc/spread_operator_for_array). The biggest change
> is I have dropped the support for string keys in v0.2 as suggested by Côme,
> to make the behavior of spread operator consistent. I have also added Q
> to explain the questions I received.
>
> Thanks & best regards,
> CHU Zhaowei
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RFC Draft: Comprehensions

[Michał Brzuchalski]

 which wouldn't at all resemble
> foreach loops and thus avoid the for/foreach confusion.
>
> Wikipedia of course has a large index of them we can mine:
>
>
> https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(list_comprehension)
>
> It appears that the most common syntax involves [] of some variety, which
> pose parsing problems for PHP, but a few other options jump out at me as
> possible syntaxes to pilfer:
>
> C# has this SQL-esque syntax (which may involve too many additional
> language keywords):
>
> var ns = from x in Enumerable.Range(0,100)
>  where x*x > 3
>  select x*2;
>
> Elixr, Erlang, and Haskell use the <- symbol, which... I don't think we
> use anywhere else currently?  In Elixir:
>
> for x <- 0..100, x * x > 3, do: x * 2
>
> Java 8, Ruby, Rust, and Swift are very very similar, and use a fluent
> syntax.  The Rust example:
>
> (0..100).filter(|x| x * x > 3).map(|x| 2 * x).collect();
>
> While that could not be taken as-is, of course, it does propose an
> interesting alternative approach, if we limit comprehensions to Traversable
> objects rather than any iterable (that is, exclude arrays):
>
> $t->filter(fn($v) => expression)->filter(fn($k, $v) =>
> expression)->map(fn($v) => expression);
>
> Which would, in turn, each produce a generator that reduces the set or
> finally yields.  I am not sure I fully like this one, to be honest, as the
> multiple inline short closures make it rather verbose and harder to follow
> with the proposed short-closure syntax (and it would involve more function
> calls internally), but it's an option.  (collect() in these languages seems
> like it's the equivalent of iterator_to_array(); maybe that's another
> alternative there as well?)
>
> Nemerle, which I've never heard of before, has this:
>
> $[x*2 | x in [0 .. 100], x*x > 3]
>
> Which, while $ is obviously already used, does suggest using one of the
> other not-yet-used sigils that Nikita identified, which would let us
> reorder the parameters to put the expression first if we wanted.  For
> example:
>
> ^[$x *2 | $k => $v in $arr if $k %2]
>
>
> In general, I see two alternatives:
>
> 1) Pass short closures and then include a special case of that special
> case that effectively gives us comprehensions over foreach, if, and yield,
> but with fewer seemingly-stray characters.
>
> 2) Steal a completely different syntax from some other language that is
> still terse but less confusing.  The main alternatives to "square brackets
> around a for loop" syntax seem to be:
>
> A) Chained filter() and map() methods
> B) SQL-like keywords
> C) Use <- somehow.
> D) Use a different starting character before the [] so that the parser
> knows some new funky order of stuff is coming.
>
> I am open to both options, of course contingent on someone willing and
> able to code it.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


Great work and I like the idea in general.

BR,
--
Michał Brzuchalski

Re: [PHP-DEV] [VOTE] Making stdClass iterable

[Michał Brzuchalski]

wt., 5 lut 2019 o 10:24 Côme Chilliet  napisał(a):

> Hello,
>
> What is the usecase for this?
>
> The RFC does not explain what it would be useful for.
> json_decode already provides an option for getting arrays instead of
> objects.
>
> All in all the RFC does not provide enough information. As I understand it
> if stdClass is Traversable then all objects are, no?
>
>
stdClass is not a super class so none of the objects in core neither
userland are derived from stdClass


> Côme
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] New website for the PHP project

[Michał Brzuchalski]

wt., 5 lut 2019 o 04:32 azjezz  napisał(a):

> ...
> mock ups : https://github.com/azjezz/web-php-mock-ups
> screenshot :
> https://github.com/azjezz/web-php-mock-ups/blob/master/screenshots/getting-started.png
>

Is this your desired look you wanna propose? I may misunderstand and
probably am.
I made a small pinboard [1] with a collection of known programming
languages websites and
thought it might be useful. When I look at some a home page usually exposes:
* short description
* example code (with an option to run)
* get started
* latest versions
* features
* why this lang and what especially for
* some latest news (not few pages as it is right now)
* etc.

When I look at your proposed landing screenshot it doesn't differ much than
what we have now, right?
You've changed the original purple colour, why?

[1] https://pl.pinterest.com/brzuchal/programming-languages/year-2019/
-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] New RFC about variables.

[Michał Brzuchalski]

Is this a joke?

pt., 25 sty 2019 o 11:32 Глеб Жуков  napisał(a):

> Hi, my name is Gleb Zhukov.
>
> In my RFC I want to propose to use a new entities(abstractions), like
> *objects*, *structures* and *data* instead of variables. It gives such
> advatege like a mental division of different, independent entities(objects,
> structures, data) in any language. For example
>
> //If earlier we were using variables to store, or access objects, data and
> everything else
>
> $object = new SomeClass();
> $array = ['one','two' => 'three'];
> $data = 'string';
>
> //Now we will use special "*object*" entities to store or access objects
> (wich may be defined with # character)
>
> #object = new SomeClass();
>
> //Special "*structure*" entities for arrays or any other structures (wich
> may be defined with * character)
>
> *stucrture = ['one', 'two', 'key' => 'val', 'another_key' =>
> 'another_val'];
>
> //And special "*data*" entities for all data (strings, integers, floats,
> booleans) (wich may be defined with % character)
>
> %string = 'abcde';
> %integer = 123;
> %floating = 1.23;
> %boolean = true;
>
> The remaining types(callables, resources), I suppose, should continue to
> store in variables. New characters for our new entities will be discussed
> further in RFC.
>


-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] Don't silence fatal errors

[Michał Brzuchalski]

I don't really know if it fits here but some weeks ago I was thinking about
annotations with "@" prefix
and was considering to propose to handle @ (silence operator) similar way
as annotations, like:

$value = @ fopen('test.txt','rb+');

might be equivalent to:

$value = @SupressError(E_ALL) fopen('test.txt','rb+');

BTW This way I believe it would be easier to parse annotations with '@'
prefix in all desired places
with one branch inside parser.

As well as there will be a place to put supression error level per
function/method call
with more specific requirements, like:

$value = @SupressError(E_ALL ^ E_ERROR) fopen('test.txt','rb+');

Which might work as supress all errors except fatal errors.

Does that sound like a solution at all?
The developer then has full controll on what errors are supressed or not.

Sorry to bother you if it's insane and crazy idea.

czw., 29 lis 2018 o 05:44 Fwentish Aelondes  napisał(a):

> Breaking BC might be unnecessary if instead of changing the default
> behavior of @, you add an additional flag to error_reporting that
> enables the new behavior, something like E_UNSILENCE_FATAL. Then
> developers would only need to switch a flag in php.ini to get the old
> behavior back, instead of re-working existing code around the new
> behavior.
>
> On 11/26/18, Nikita Popov  wrote:
> >  Hi internals,
> >
> > When the silencing operator @ is used, the intention is generally to
> > silence expected warnings or notices. However, it currently also silences
> > fatal errors. As fatal errors also abort request execution, the result
> will
> > often be a hard to debug white screen of death.
> >
> > The most recent occurrence which motivated me to write this mail is
> > https://bugs.php.net/bug.php?id=77205, but I've seen this play out
> multiple
> > times already.
> >
> > I would like to propose to change the behavior of @ to only silence
> > warnings, notices and other low-level diagnostics, but leave fatal errors
> > intake. In particular, the following should not be silenced:
> >
> > * E_ERROR
> > * E_CORE_ERROR
> > * E_COMPILE_ERROR
> > * E_USER_ERROR
> > * E_RECOVERABLE_ERROR
> > * E_PARSE
> >
> > This change would have two main implications for backwards compatibility:
> >
> > 1. Code that legitimately wants to silence fatal errors for whatever
> reason
> > should now use error_reporting() (or ini_set()) to do so, instead of @.
> >
> > 2. Error handlers that want to only handle non-silenced errors may have
> to
> > be adjusted. A common pattern I found in our own tests if checks for
> > error_reporting() != 0 to detect silencing. This should be changed to
> > error_reporting() & $err_no to detect whether the specific error type is
> > silenced.
> >
> > A preliminary patch for this change is available at
> > https://github.com/php/php-src/pull/3685.
> >
> > What do you think about this?
> >
> > Nikita
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC][Discuss] Covariant return- and contravariant parameter- types

[Michał Brzuchalski]

Can't wait for it to happen!
Thank you for your work and fixing object type.

pon., 26 lis 2018 o 22:26 Levi Morrison  napisał(a):

> I am happy to announce my latest RFC, [Covariant Returns and
> Contravariant Parameters][1], is open for discussion. If you do not
> recognize those terms then hopefully the introduction coupled with the
> [examples][2] will help. Here is one snippet that demonstrates
> covariant return types:
>
>  interface Repository {
>   function fetch(int $id): ?Entity;
> }
>
> class UserFactory implements Repository {
>   function fetch(int $id): ?UserEntity {
> /* Since UserEntity is an Entity, this is now allowed */
> /* ... implementation ... */
>   }
> }
> ?>
>
> Covariant return types and contravariant parameter types are highly
> requested features; here are a few of the bug reports:
>
>   * https://bugs.php.net/bug.php?id=71825
>   * https://bugs.php.net/bug.php?id=72442
>   * https://bugs.php.net/bug.php?id=75385
>   * https://bugs.php.net/bug.php?id=75823
>
> There is a [preliminary implementation][3] that is available. It will
> not be rebased during discussion to allow people to check out the code
> and get updates without worrying about it breaking. The code quality
> can definitely be improved, and there are still a few todo comments in
> the code.
>
> Please do not discuss the items found in [Future Scope][4] as part of
> this thread, which includes discussing types such as `mixed`,
> `scalar`, `numeric`, etc.
>
> I look forward to your feedback, and especially with your
> experimentation with the implementation.
>
> Levi Morrison
>
>   [1]:
> https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters
>   [2]:
> https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters#examples
>   [3]:
> https://github.com/php/php-src/compare/master...morrisonlevi:variance2
>   [4]:
> https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters#future_scope
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

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

[Michał Brzuchalski]

śr., 27 cze 2018 o 16:55 Michał Brzuchalski 
napisał(a):

>
>
> śr., 27 cze 2018 o 03:29 Rudolf Theunissen 
> napisał(a):
>
>> > 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
>>
>>
> It was possible in Sara's extension[1], so maybe now also? Take a look.
>
>
>
>> Actually not sure this can be done as an extension because it changes
>> zend_operators and introduces a new handler to make it all work.
>>
>> > 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 == $b must not work if $a->__equals and $b->__equals
>> are
>> two different functions
>>
>> So effectively it means we only call __equals if both sides are instances
>> of the same class?
>>
>> > If $left operand and $right operand both have the magic methods, it will
>> call $left->__magic($right), otherwise, if only the right one has the
>> handler? What if the right one has compareTo and the left has only equal?
>> you probably should add a table that explains which method is called
>> depending in the availability of the two magic methods in the operands.
>>
>> Good idea. :) In brief, as it's implemented right now, the LHS takes
>> precedence and the RHS will be called if it's the only one that implements
>> the operation. I'll write some more tests for these cases and build that
>> table for the RFC.
>>
>> > I'd introduce a debug mode that forces php to call both
>> $left->__equals($right) and $right->__equals($left) so that symmetry is
>> guaranteed by design.
>>
>> If we want to guarantee symmetry by design, we have to either compare both
>> sides or only compare if instances of the same class, or document that
>> comparison should be implemented such that a > b == b < a, etc. I'm not
>> convinced that a double comparison outweighs the responsibility on the
>> user
>> to be sensible.
>>
>> On Tue, 26 Jun 2018 at 21:04, Wes  wrote:
>>
>> > 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 == $b must not work if $a->__equals and $b->__equals
>> > are two different functions
>> >
>> > - otherwise RFC should specify the precedence. if $left operand and
>> $right
>> > operand both have the magic methods, it will call
>> $left->__magic($right),
>> > otherwise, if only the right one has the handler?
>> >   what if the right one has compareTo and the left has only equal? you
>> > probably should add a table that explains which method is called
>> depending
>> > in the availability of the two magic methods in the operands.
>> >
>> > - I'd introduce a debug mode that forces php to call both
>> > $left->__equals($right) and $right->__equals($left) so that symmetry is
>> > guaranteed by design. You could do that when "assertions" are active.
>> >
>> > gl
>> >
>>
>
> [1] https://github.com/php/pecl-php-operator/blob/master/operator.c
> --
> regards / pozdrawiam,
> --
> Michał Brzuchalski
> about.me/brzuchal
> brzuchalski.com
>


There is also one more thing I can think of. If __equals and __compareTo
methods
don't have any restrictions for $other parameter typehint then I'll be able
to declare
Foo {
public function __compareTo(int $other): int {}
}
and will get some error on
new Foo() == new DateTime('now');

Right?

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

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

[Michał Brzuchalski]

śr., 27 cze 2018 o 03:29 Rudolf Theunissen 
napisał(a):

> > 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
>
>
It was possible in Sara's extension[1], so maybe now also? Take a look.



> Actually not sure this can be done as an extension because it changes
> zend_operators and introduces a new handler to make it all work.
>
> > 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 == $b must not work if $a->__equals and $b->__equals are
> two different functions
>
> So effectively it means we only call __equals if both sides are instances
> of the same class?
>
> > If $left operand and $right operand both have the magic methods, it will
> call $left->__magic($right), otherwise, if only the right one has the
> handler? What if the right one has compareTo and the left has only equal?
> you probably should add a table that explains which method is called
> depending in the availability of the two magic methods in the operands.
>
> Good idea. :) In brief, as it's implemented right now, the LHS takes
> precedence and the RHS will be called if it's the only one that implements
> the operation. I'll write some more tests for these cases and build that
> table for the RFC.
>
> > I'd introduce a debug mode that forces php to call both
> $left->__equals($right) and $right->__equals($left) so that symmetry is
> guaranteed by design.
>
> If we want to guarantee symmetry by design, we have to either compare both
> sides or only compare if instances of the same class, or document that
> comparison should be implemented such that a > b == b < a, etc. I'm not
> convinced that a double comparison outweighs the responsibility on the user
> to be sensible.
>
> On Tue, 26 Jun 2018 at 21:04, Wes  wrote:
>
> > 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 == $b must not work if $a->__equals and $b->__equals
> > are two different functions
> >
> > - otherwise RFC should specify the precedence. if $left operand and
> $right
> > operand both have the magic methods, it will call $left->__magic($right),
> > otherwise, if only the right one has the handler?
> >   what if the right one has compareTo and the left has only equal? you
> > probably should add a table that explains which method is called
> depending
> > in the availability of the two magic methods in the operands.
> >
> > - I'd introduce a debug mode that forces php to call both
> > $left->__equals($right) and $right->__equals($left) so that symmetry is
> > guaranteed by design. You could do that when "assertions" are active.
> >
> > gl
> >
>

[1] https://github.com/php/pecl-php-operator/blob/master/operator.c
-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] Equality and relative ordering of objects

[Michał Brzuchalski]

ual the integer `2`, but
> their
> relative ordering is the same, and a comparison would return `0`.
>

That's true, but you want to compare objects not scalar types, right?


>
> 3. The contexts in which they are called are not the same. Testing for
> equality
> occurs when an object is compared with another using `==` or in functions
> like `array_search`. The question we're asking is whether the two values
> are
> considered equal, and we're not concerned with ordering. The context for
> comparison is when we need to determine the relative ordering of two values
> using `<`, `>`, or in functions like `sort`.
>
>
> Issues to be discussed:
>
> 1. What happens when we use `<=` and `>=`? Does the "or equal to" part call
> `__equals` or does it check if `__compareTo` returns 0?
>
> 2. Should we also expose strict comparison, ie. `===` ?
>
> 3. Naming:
> - `__eq`
> - `__equalTo`
> - `__equals`
> - `__compareTo`
> - `__comparedTo`
> - `__compare`
> - `__cmp`
>

Thanks for reanimating this subject.

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] xmlrpc extension maintainership?

[Michał Brzuchalski]

Hi Stas,

I know this is a different thread but looking at the list I think I can try
to take my chances in fixing bugs in sys*.
Some time ago I started from sysvshm because I wanted to change it to not
use resources https://github.com/php/php-src/pull/3235 and was planning to
go with sysvsem and sysvmsg as well.
I was looking at related bugs, some of them are feature requests, some of
them waiting for review and PR and some like this one on CentOS 6  needs
more attention.
I'm not a C ninja but hope my skills and a little amount of free time which
sometimes I find may be enough. If so what shall I do next?

Regards,
Michal

pon., 18 cze 2018 o 01:15 Stanislav Malyshev 
napisał(a):

> Hi!
>
> > is there a list available with unmaintained extensions which are still
> > inside the core?
>
> Current list is here: https://wiki.php.net/todo/extensions
>
> This may change periodically.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] Strict switch statements

[Michał Brzuchalski]

2018-06-15 11:44 GMT+02:00 Christoph M. Becker :

> On 15.06.2018 at 08:36, Sebastian Bergmann wrote:
>
> > Am 14.06.2018 um 10:35 schrieb Nikita Popov:
> >
> >> It might make sense to introduce an entirely new "match" statement
> >> that conforms a bit more with how switch-like strictures are
> >> implemented  nowadays. That is, something like
> >>
> >> match ($expr) {
> >> "foo" => {...},
> >> "bar" | "baz" => {...},
> >> }
> >>
> >> or similar.
> >
> > Interesting. Can you provide a pointer to a language that has a match
> > statement like that?
>
> This match statement (or would it be an expression?) could be regarded
> as an extremly simplified syntactic variant of the case-of expression of
> Standard ML[1].
>
> Instead of the pipe operator we could use a comma to separate multiple
> “patterns”.  Using “case” instead of “match” appears to be something to
> consider as well.
>
> [1]
> <https://www.cs.cornell.edu/courses/cs312/2004fa/lectures/lecture3.htm>,
> section “Pattern Matching”
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
It's just a thought but maybe providing a new declare directive
like `declare(strict_comparison=1);` be easier for those who prefer strict
everywhere?
We have `declare(strict_types=1);` so we may have stricter declares also.
Maybe someday it turns into a standard way of working with PHP and can get
rid of declares without any code changes.
This may result in all comparisons strict without type juggling and won't
need any syntax changes at all.
And it'll apply for switch,if,else,ifselse,for,while etc. in all
comparisons.

Or maybe `declare(no_type_juggling=1)` or smth like that.

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] PHP FFI extenesion

[Michał Brzuchalski]

One more idea I can imagine - while creating FFI object would it be
possible to:
* declare all ZEND_FFI_SYM_FUNC as class methods with proper type hinting
mapped to registered classes
* declare all ZEND_FFI_SYM_VAR as class properties with some guards
* declare all ZEND_FFI_SYM_CONST as class public consts

It would be possible to use reflection then.
But that I suppose should require extending FFI and registering symbols
into newly created class_entry.
It is possible that I'm overcoming and inventing right now. If so, just
ignore me :)

2018-04-17 10:55 GMT+02:00 Dmitry Stogov <dmi...@zend.com>:

> Now, I got your idea.
>
> Subclassing CData, and use that types for type hinting may make sense.
>
> I'll put this idea in my TODO, but with low priority.
>
>
> Thanks. Dmitry.
> ------
> *From:* Michał Brzuchalski <mic...@brzuchalski.com>
> *Sent:* Tuesday, April 17, 2018 10:51:32 AM
>
> *To:* Dmitry Stogov
> *Cc:* Stanislav Malyshev; Zeev Suraski; Xinchen Hui; Nikita Popov; Bob
> Weinand; Anatol Belski (a...@php.net); PHP internals list
> *Subject:* Re: [PHP-DEV] PHP FFI extenesion
>
>
>
> 2018-04-17 9:46 GMT+02:00 Dmitry Stogov <dmi...@zend.com>:
>
> Hi Michal,
>
>
> I didn't think in this way. I liked to make the simplest API.
>
> I don't expect wide FFI usage in frameworks :)
>
>
> BTW: I like the idea of use C type names (probably, we may reuse original
> C type names without additional registration).
>
>
> currently we can do: $tz = $libc->new("struct timezone");
>
>
> My point was ability to provide an identity to objects wich acts as a
> structs. CData class has no idea of what struct type it is and I cannot
> type hint over that, thats why I thought it would be usefull.
> I could then prepare a vendor using pure PHP and wrap everything using
> types.
>
>
>
> I'll think, if we can existend API to use something like: $tz =
> FFI::new($libc->timezone);
>
> At least, this should eliminate C parsing overhead.
>
>
> Thanks. Dmitry.
> --
> *From:* Michał Brzuchalski <mic...@brzuchalski.com>
> *Sent:* Tuesday, April 17, 2018 10:24:02 AM
> *To:* Dmitry Stogov
> *Cc:* Stanislav Malyshev; Zeev Suraski; Xinchen Hui; Nikita Popov; Bob
> Weinand; Anatol Belski (a...@php.net); PHP internals list
> *Subject:* Re: [PHP-DEV] PHP FFI extenesion
>
> Hi Dmitry!
>
> I am not much experienced with C but as a user, I'm just wondering if
> there is a possibility to extend FFI class and autoregister all or just
> chosen structs as classes, for eg.
> class Libc extends FFI {
> public function __construct() {
> parent::__construct("...code", "...lib"); // tmp notation
> $this->register('struct timeval', Libc\Timeval::class); // I
> assume they would extend CData
> $this->register('struct timezone', Libc\Timezone::class); // as
> above
> }
> }
>
> So I can instantiate
>
> $tz = new Libc\Timezone();
> $tv = new Libc\Timeval();
>
> and then pass them FFI function
>
> (new Libc())->gettimeofday($tv, $tz);
> var_dump($tv-tv_sec, $tv->tv_usec, $tz);
>
> I would be able to prepare than a vendor package with a specified
> autoloader.
> Would that make sense?
>
> Also wouldn't it better if CData class share the same prefixes like
> FFICdata or FFI\CData?
>
>
> Cheers,
> Michal
>
> 2018-04-17 9:18 GMT+02:00 Dmitry Stogov <dmi...@zend.com>:
>
>
>
> On Apr 17, 2018 2:49 AM, Stanislav Malyshev <smalys...@gmail.com> wrote:
> Hi!
>
> > I've spent some time thinking about simple FFI for PHP, and finally,
> borrowed most ideas from LuaJIT.
> >
> > This is an initial PoC. It was tested on Linux only.
> >
> >
> > https://github.com/dstogov/php-ffi
> >
> >
> > I would appreciate review, comments and ideas about missing features and
> functionality.
> >
>
> Looks interesting. On a cursory look, couple of thoughts:
> - I think all the classes involved should be made non-serializable and
> non-unserializable.
>
> Agree.
>
> - Does it load shared libraries, or only uses ones already loaded? If
> the former, I think there should be a way to unload them at the request
> end (even though it might be performance issue, and may be not possible
> if persistent resources are involved), otherwise we leak state between
> requests.
>
> I have a bit opposit idea. We will keep FFI for CLI but disable it for web
> apps (like dl()).
> At the same time, we will develop a technology to preload and reuse  PHP
> files across requests.
> And allow FFI there.
>
> - OTOH, people m

Re: [PHP-DEV] PHP FFI extenesion

[Michał Brzuchalski]

2018-04-17 9:46 GMT+02:00 Dmitry Stogov <dmi...@zend.com>:

> Hi Michal,
>
>
> I didn't think in this way. I liked to make the simplest API.
>
> I don't expect wide FFI usage in frameworks :)
>
>
> BTW: I like the idea of use C type names (probably, we may reuse original
> C type names without additional registration).
>
>
> currently we can do: $tz = $libc->new("struct timezone");
>

My point was ability to provide an identity to objects wich acts as a
structs. CData class has no idea of what struct type it is and I cannot
type hint over that, thats why I thought it would be usefull.
I could then prepare a vendor using pure PHP and wrap everything using
types.


>
> I'll think, if we can existend API to use something like: $tz =
> FFI::new($libc->timezone);
>
> At least, this should eliminate C parsing overhead.
>
>
> Thanks. Dmitry.
> --
> *From:* Michał Brzuchalski <mic...@brzuchalski.com>
> *Sent:* Tuesday, April 17, 2018 10:24:02 AM
> *To:* Dmitry Stogov
> *Cc:* Stanislav Malyshev; Zeev Suraski; Xinchen Hui; Nikita Popov; Bob
> Weinand; Anatol Belski (a...@php.net); PHP internals list
> *Subject:* Re: [PHP-DEV] PHP FFI extenesion
>
> Hi Dmitry!
>
> I am not much experienced with C but as a user, I'm just wondering if
> there is a possibility to extend FFI class and autoregister all or just
> chosen structs as classes, for eg.
> class Libc extends FFI {
> public function __construct() {
> parent::__construct("...code", "...lib"); // tmp notation
> $this->register('struct timeval', Libc\Timeval::class); // I
> assume they would extend CData
> $this->register('struct timezone', Libc\Timezone::class); // as
> above
> }
> }
>
> So I can instantiate
>
> $tz = new Libc\Timezone();
> $tv = new Libc\Timeval();
>
> and then pass them FFI function
>
> (new Libc())->gettimeofday($tv, $tz);
> var_dump($tv-tv_sec, $tv->tv_usec, $tz);
>
> I would be able to prepare than a vendor package with a specified
> autoloader.
> Would that make sense?
>
> Also wouldn't it better if CData class share the same prefixes like
> FFICdata or FFI\CData?
>
>
> Cheers,
> Michal
>
> 2018-04-17 9:18 GMT+02:00 Dmitry Stogov <dmi...@zend.com>:
>
>
>
> On Apr 17, 2018 2:49 AM, Stanislav Malyshev <smalys...@gmail.com> wrote:
> Hi!
>
> > I've spent some time thinking about simple FFI for PHP, and finally,
> borrowed most ideas from LuaJIT.
> >
> > This is an initial PoC. It was tested on Linux only.
> >
> >
> > https://github.com/dstogov/php-ffi
> >
> >
> > I would appreciate review, comments and ideas about missing features and
> functionality.
> >
>
> Looks interesting. On a cursory look, couple of thoughts:
> - I think all the classes involved should be made non-serializable and
> non-unserializable.
>
> Agree.
>
> - Does it load shared libraries, or only uses ones already loaded? If
> the former, I think there should be a way to unload them at the request
> end (even though it might be performance issue, and may be not possible
> if persistent resources are involved), otherwise we leak state between
> requests.
>
> I have a bit opposit idea. We will keep FFI for CLI but disable it for web
> apps (like dl()).
> At the same time, we will develop a technology to preload and reuse  PHP
> files across requests.
> And allow FFI there.
>
> - OTOH, people may want to load a set of persistent definitions from a
> config file, etc. - the ffi definition probably won't change much, and
> having locked down set of FFI interfaces the rest of the code is using
> might be beneficial
>
> Yeah. Like this.
>
> - Since this thing is dealing with raw pointers, etc., from PHP code,
> there may be a lot of crashes from using this extension in a wrong way.
> I wonder which facilities we could provide for helping people to debug
> it (for people who aren't super-comfortable using gdb on PHP engine).
>
> Programming using FFI, is very similar to C.
> I'm not sure, if we may provide good debugging facilities.
>
> Thanks for review.
>
> Dmitry.
>
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> Hi!
>
> > I've spent some time thinking about simple FFI for PHP, and finally,
> borrowed most ideas from LuaJIT.
> >
> > This is an initial PoC. It was tested on Linux only.
> >
> >
> > https://github.com/dstogov/php-ffi
> >
> >
> > I would appreciate review, comments and ideas about missing features and
> functionality.
> >
>
> Looks interesting. On a curso

Re: [PHP-DEV] PHP FFI extenesion

[Michał Brzuchalski]

Hi Dmitry!

I am not much experienced with C but as a user, I'm just wondering if there
is a possibility to extend FFI class and autoregister all or just chosen
structs as classes, for eg.
class Libc extends FFI {
public function __construct() {
parent::__construct("...code", "...lib"); // tmp notation
$this->register('struct timeval', Libc\Timeval::class); // I assume
they would extend CData
$this->register('struct timezone', Libc\Timezone::class); // as
above
}
}

So I can instantiate

$tz = new Libc\Timezone();
$tv = new Libc\Timeval();

and then pass them FFI function

(new Libc())->gettimeofday($tv, $tz);
var_dump($tv-tv_sec, $tv->tv_usec, $tz);

I would be able to prepare than a vendor package with a specified
autoloader.
Would that make sense?

Also wouldn't it better if CData class share the same prefixes like
FFICdata or FFI\CData?


Cheers,
Michal

2018-04-17 9:18 GMT+02:00 Dmitry Stogov <dmi...@zend.com>:

>
>
> On Apr 17, 2018 2:49 AM, Stanislav Malyshev <smalys...@gmail.com> wrote:
> Hi!
>
> > I've spent some time thinking about simple FFI for PHP, and finally,
> borrowed most ideas from LuaJIT.
> >
> > This is an initial PoC. It was tested on Linux only.
> >
> >
> > https://github.com/dstogov/php-ffi
> >
> >
> > I would appreciate review, comments and ideas about missing features and
> functionality.
> >
>
> Looks interesting. On a cursory look, couple of thoughts:
> - I think all the classes involved should be made non-serializable and
> non-unserializable.
>
> Agree.
>
> - Does it load shared libraries, or only uses ones already loaded? If
> the former, I think there should be a way to unload them at the request
> end (even though it might be performance issue, and may be not possible
> if persistent resources are involved), otherwise we leak state between
> requests.
>
> I have a bit opposit idea. We will keep FFI for CLI but disable it for web
> apps (like dl()).
> At the same time, we will develop a technology to preload and reuse  PHP
> files across requests.
> And allow FFI there.
>
> - OTOH, people may want to load a set of persistent definitions from a
> config file, etc. - the ffi definition probably won't change much, and
> having locked down set of FFI interfaces the rest of the code is using
> might be beneficial
>
> Yeah. Like this.
>
> - Since this thing is dealing with raw pointers, etc., from PHP code,
> there may be a lot of crashes from using this extension in a wrong way.
> I wonder which facilities we could provide for helping people to debug
> it (for people who aren't super-comfortable using gdb on PHP engine).
>
> Programming using FFI, is very similar to C.
> I'm not sure, if we may provide good debugging facilities.
>
> Thanks for review.
>
> Dmitry.
>
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> Hi!
>
> > I've spent some time thinking about simple FFI for PHP, and finally,
> borrowed most ideas from LuaJIT.
> >
> > This is an initial PoC. It was tested on Linux only.
> >
> >
> > https://github.com/dstogov/php-ffi
> >
> >
> > I would appreciate review, comments and ideas about missing features and
> functionality.
> >
>
> Looks interesting. On a cursory look, couple of thoughts:
> - I think all the classes involved should be made non-serializable and
> non-unserializable.
> - Does it load shared libraries, or only uses ones already loaded? If
> the former, I think there should be a way to unload them at the request
> end (even though it might be performance issue, and may be not possible
> if persistent resources are involved), otherwise we leak state between
> requests.
> - OTOH, people may want to load a set of persistent definitions from a
> config file, etc. - the ffi definition probably won't change much, and
> having locked down set of FFI interfaces the rest of the code is using
> might be beneficial
> - Since this thing is dealing with raw pointers, etc., from PHP code,
> there may be a lot of crashes from using this extension in a wrong way.
> I wonder which facilities we could provide for helping people to debug
> it (for people who aren't super-comfortable using gdb on PHP engine).
>
> --
> Stas Malyshev
> smalys...@gmail.com
>



-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV][RFC][DISCUSSION] Strong Typing Syntax

[Michał Brzuchalski]

 not to do that and use a separate flag for one or both of
> these methods. While I can live with that I would like to point out that
> debug flag proliferation can lead to confusion.
>
> The crux of my argument for using the zend.assertion flag is that these
> type checks are all, at the end of day, engine level assertions. PHP ships
> with zend.assertion set to 1, and with PHP 8 we can keep that default and
> recommend to providers to not assume it's safe to set it to -1 since there
> is a small, but not insignificant, chance that old code relying on Type
> declarations to be on might corrupt user data.  I admit this would be
> painful in the short term, but it is better for the long term health of the
> language and parser.
>
>
>
>
> CONCLUSION
> I believe that covers all the bases needed. This will give those who want
> things to use strong typing better tools, and those who don't can be free
> to ignore them.
>

Please register a wiki account and put proposed RFC to the RFC's list.

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

13.12.2017 11:44 "Tony Marston"  napisał(a):

""Michal Brzuchalski""  wrote in message news:CABdc3WpomNLz+vX_m0B0wQ3u
cimiw8xw4ea_sgd-ptdgfv-...@mail.gmail.com...


> 2017-12-13 1:16 GMT+01:00 Andreas Hennings :
>
> 


> Why? Because users use PSR-4 so then they're src folder looks more like:
>
?


You are assuming that everybody is using PSR-4. That is a wrong assumption
to make.


I didn't say everybody at all! Please read carefully.


-- 
Tony Marston



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

2017-12-13 6:04 GMT+01:00 Michał Brzuchalski <mic...@brzuchalski.com>:

>
>
> 2017-12-13 5:38 GMT+01:00 Michał Brzuchalski <mic...@brzuchalski.com>:
>
>>
>>
>> 2017-12-13 5:24 GMT+01:00 Andreas Hennings <andr...@dqxtech.net>:
>>
>>> On 13 December 2017 at 05:04, Michał Brzuchalski <mic...@brzuchalski.com>
>>> wrote:
>>> >
>>> > If we're going to introduce someday a namespace file, then IMO it
>>> should not
>>> > be putted outside namespace folder.
>>> > For eg class Acme\Animal\Cat in src/Acme/Animal/Cat.php should have
>>> > namespace file in src/Acme/Aniimal/namespace.php
>>> > or even more src/Acme/Animal/ns.php
>>> > Why? Because users use PSR-4 so then they're src folder looks more
>>> like:
>>> > src/Cat.php <-- class Acme\Animal\Cat
>>> > src/ns.php <-- that should be then a place for namespace declare or
>>> even
>>> > function and constants.
>>>
>>> You are right, my previous proposal src/Acme/Animal.namespace.php
>>> would not work universally.
>>>
>>> But your proposal, src/Acme/Animal/ns.php clashes with the class file
>>> for class \Acme\Animal\ns.
>>>
>>> We would need something other than NAME.php.
>>> E.g. src/Acme/Animal/ns.inc.php
>>>
>>
> Actually not true. `namespace` keyword is reserved and none class can have
> such name.
> This means this example couses a syntax error:
>
>  namespace Acme\Animals;
> class namespace {}
>
> That why we can assume we can utilise namespace.php file name.
> And also why not trying to include it on autoload call?
> For eg.
> 
> new Acme\Animal\Cat(); // tries to load $file = "src/Acme/Animal/Cat.php"
>
> // but prevoiusly tries to load
> require_once dirname($file) . DIRECTORY_SEPARATOR . 'namespace.php';
>
> It's bad because it';s magic, but the `namespace.php` filename is still
> available to use.
>
>
Andreas, we're touching namespaces which is a hard subject, but if I could
fly away with my thoughts
I'd propose to introduce something called for eg. a package and then
divide it's name in class/function/const name with a single colon, for eg.
Acme:Animal\Cat
which gives additional information about package which then declares
something and may be
a good start for future scoped declarations.

I've prepared a short gist to illustrate that
https://gist.github.com/brzuchal/352ffce2717648f0d43f2d5a0c4bfb7b

This solution doesn't require usage of Composer, but needs to pass an
aotuloader function a type to load.
There was a proposal on internal some time ago to pass additional parameter
to load function.


>
>>> But then Composer would still need to make sure that this file is
>>> always included before any class files from this directory.
>>> On language level we cannot assume that Composer is being used, and
>>> that it is being used correctly.
>>>
>>> So again this would be fragile.
>>>
>>> >
>>> > Such namespace file can be a good place for namespace function and
>>> constants
>>> > declaration.
>>> > Also I think there is no need for another global function named
>>> > `namespace_declare` if we had namespace file
>>> > then we can utilise declare for that.
>>> > Lets imagine such syntax:
>>> >
>>> > // src/Acme/Animal/ns.php
>>> > >> >
>>> > namespace Acme\Animal declare(strict_types=1,another_option=0);
>>> > const CAT = 1;
>>> > function createCat() : Cat {}
>>>
>>> This means you are changing the meaning of existing declare() to apply
>>> to the entire namespace?
>>> Or to the entire directory?
>>>
>>>
>> To entire namespace just like:
>>
>> >
>> namespace_declare('Acme\Animal', [
>> 'strict_types' => 1,
>> 'dynamic_object_properties' => 0,
>> ...
>> ]);
>>
>> namespace Acme\Animal declare(
>> strict_types=1,
>> dynamic_object_properties=0
>> ); // <-- this works same as namespace_declare call above
>>
>> namespace Acme\Machines {
>> // here we have strict_types=0 turned off
>> }
>>
>>
>>> Or maybe the difference here is that there is no semicolon directly
>>> after the namespace declaration?
>>>
>>> I am not convinced by this syntax.
>>> But even if we would find a good syntax, the behavioral problems
>>> pointed out by Stanislav still apply.
>>>
>>
>>
>>
>> --
>> regards / pozdrawiam,
>> --
>> Michał Brzuchalski
>> about.me/brzuchal
>> brzuchalski.com
>>
>
>
>
> --
> regards / pozdrawiam,
> --
> Michał Brzuchalski
> about.me/brzuchal
> brzuchalski.com
>



-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

2017-12-13 5:38 GMT+01:00 Michał Brzuchalski <mic...@brzuchalski.com>:

>
>
> 2017-12-13 5:24 GMT+01:00 Andreas Hennings <andr...@dqxtech.net>:
>
>> On 13 December 2017 at 05:04, Michał Brzuchalski <mic...@brzuchalski.com>
>> wrote:
>> >
>> > If we're going to introduce someday a namespace file, then IMO it
>> should not
>> > be putted outside namespace folder.
>> > For eg class Acme\Animal\Cat in src/Acme/Animal/Cat.php should have
>> > namespace file in src/Acme/Aniimal/namespace.php
>> > or even more src/Acme/Animal/ns.php
>> > Why? Because users use PSR-4 so then they're src folder looks more like:
>> > src/Cat.php <-- class Acme\Animal\Cat
>> > src/ns.php <-- that should be then a place for namespace declare or even
>> > function and constants.
>>
>> You are right, my previous proposal src/Acme/Animal.namespace.php
>> would not work universally.
>>
>> But your proposal, src/Acme/Animal/ns.php clashes with the class file
>> for class \Acme\Animal\ns.
>>
>> We would need something other than NAME.php.
>> E.g. src/Acme/Animal/ns.inc.php
>>
>
Actually not true. `namespace` keyword is reserved and none class can have
such name.
This means this example couses a syntax error:

> But then Composer would still need to make sure that this file is
>> always included before any class files from this directory.
>> On language level we cannot assume that Composer is being used, and
>> that it is being used correctly.
>>
>> So again this would be fragile.
>>
>> >
>> > Such namespace file can be a good place for namespace function and
>> constants
>> > declaration.
>> > Also I think there is no need for another global function named
>> > `namespace_declare` if we had namespace file
>> > then we can utilise declare for that.
>> > Lets imagine such syntax:
>> >
>> > // src/Acme/Animal/ns.php
>> > > >
>> > namespace Acme\Animal declare(strict_types=1,another_option=0);
>> > const CAT = 1;
>> > function createCat() : Cat {}
>>
>> This means you are changing the meaning of existing declare() to apply
>> to the entire namespace?
>> Or to the entire directory?
>>
>>
> To entire namespace just like:
>
> 
> namespace_declare('Acme\Animal', [
> 'strict_types' => 1,
> 'dynamic_object_properties' => 0,
> ...
> ]);
>
> namespace Acme\Animal declare(
> strict_types=1,
> dynamic_object_properties=0
> ); // <-- this works same as namespace_declare call above
>
> namespace Acme\Machines {
> // here we have strict_types=0 turned off
> }
>
>
>> Or maybe the difference here is that there is no semicolon directly
>> after the namespace declaration?
>>
>> I am not convinced by this syntax.
>> But even if we would find a good syntax, the behavioral problems
>> pointed out by Stanislav still apply.
>>
>
>
>
> --
> regards / pozdrawiam,
> --
> Michał Brzuchalski
> about.me/brzuchal
> brzuchalski.com
>



-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

2017-12-13 5:24 GMT+01:00 Andreas Hennings <andr...@dqxtech.net>:

> On 13 December 2017 at 05:04, Michał Brzuchalski <mic...@brzuchalski.com>
> wrote:
> >
> > If we're going to introduce someday a namespace file, then IMO it should
> not
> > be putted outside namespace folder.
> > For eg class Acme\Animal\Cat in src/Acme/Animal/Cat.php should have
> > namespace file in src/Acme/Aniimal/namespace.php
> > or even more src/Acme/Animal/ns.php
> > Why? Because users use PSR-4 so then they're src folder looks more like:
> > src/Cat.php <-- class Acme\Animal\Cat
> > src/ns.php <-- that should be then a place for namespace declare or even
> > function and constants.
>
> You are right, my previous proposal src/Acme/Animal.namespace.php
> would not work universally.
>
> But your proposal, src/Acme/Animal/ns.php clashes with the class file
> for class \Acme\Animal\ns.
>
> We would need something other than NAME.php.
> E.g. src/Acme/Animal/ns.inc.php
>
> But then Composer would still need to make sure that this file is
> always included before any class files from this directory.
> On language level we cannot assume that Composer is being used, and
> that it is being used correctly.
>
> So again this would be fragile.
>
> >
> > Such namespace file can be a good place for namespace function and
> constants
> > declaration.
> > Also I think there is no need for another global function named
> > `namespace_declare` if we had namespace file
> > then we can utilise declare for that.
> > Lets imagine such syntax:
> >
> > // src/Acme/Animal/ns.php
> >  >
> > namespace Acme\Animal declare(strict_types=1,another_option=0);
> > const CAT = 1;
> > function createCat() : Cat {}
>
> This means you are changing the meaning of existing declare() to apply
> to the entire namespace?
> Or to the entire directory?
>
>
To entire namespace just like:

 1,
'dynamic_object_properties' => 0,
...
]);

namespace Acme\Animal declare(
strict_types=1,
dynamic_object_properties=0
); // <-- this works same as namespace_declare call above

namespace Acme\Machines {
// here we have strict_types=0 turned off
}


> Or maybe the difference here is that there is no semicolon directly
> after the namespace declaration?
>
> I am not convinced by this syntax.
> But even if we would find a good syntax, the behavioral problems
> pointed out by Stanislav still apply.
>



-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

r that.
Lets imagine such syntax:

// src/Acme/Animal/ns.php
 I haven't thought too carefully about whether having an option for the
> > explicit-send-by-ref feature *specifically* would be beneficial, but I
> > think it's very important to at least have the option on the table. Too
> > many issues in PHP cannot be solved for reasons of
> backwards-compatibility.
> > We need to have *some* way to evolve the language without BC breaks, and
> I
> > think namespace-declares are an elegant way to do this.
>
>
> So if you want a setting for explicit-send-by-ref, why not do this per
> file, as we already do for strict_types?
>
> If at some day in the future we find that the declares become too
> verbose, we could bundle multiple declares into a new setting.
> E.g. something like "declare(php=8.1);" to combine all the declares
> that would be considered default in PHP 8.1.
>
> Or introduce some other shortcut like " opening tag.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] Pre-draft for PipeOp v2

[Michał Brzuchalski]

2017-09-28 21:07 GMT+02:00 Levi Morrison <le...@php.net>:

> On Wed, Sep 27, 2017 at 1:56 PM, Sara Golemon <poll...@php.net> wrote:
>
> > On Thu, Sep 21, 2017 at 5:13 PM, Stanislav Malyshev <smalys...@gmail.com
> >
> > wrote:
> > > It'd be also nice then if we could have some syntax that allowed us to
> > > refer to functions/methods as callables - mostly for the benefit of the
> > > code readers and IDEs. I.e. you can do "hello" |> "strtoupper" and it's
> > > fine but it is not at all intuitive what you're doing sending one
> string
> > > into another. Same with "hello" |> [$this, 'bar']. Now, if we could do
> > > something like this:
> > > "hello" |> &{strtoupper}
> > > "hello" |> &{$this->bar}
> > >
> > Super-hacky implementation (that I wouldn't want to merge, but it
> > shows the syntax at work).
> >
> > https://github.com/php/php-src/compare/master...sgolemon:lambda
> > which provides a form of both short-closures and partial functions.
> >
> > Combined with also-super-hacky pipe diff from earlier, you get:
> >
> > $x = "Hello"
> >   |> &{strtoupper($0)}
> >   |> &{ $0 . "world" }
> >   |> &{strrev($0)};
> >
> > var_dump($x);
> > // string(10) "dlrowOLLEH"
> >
> > -Sara
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> By the way the `&` is not required. When experimenting with possible short
> closure syntax I created an implementation for `{}` to make sure it was
> possible:
>
>   $x = "Hello"
> |> {strtoupper($0)}
> |> { $0 . "world" }
> |> {strrev($0)};
>
> If people would prefer that syntax for short-closures then that's fine by
> me. If we made it this concise there wouldn't be a need for a `$$` proposal
> anyway.
>

I love this syntax with braces, I wanted to do like it in
https://wiki.php.net/rfc/short-closures
but only for replacement of string or array callables as closures.


>
> ---
>
> My impression from the community is that the pipe operator is desirable but
> not if it encourages string or array callables. In that vein which syntax
> do you prefer?
>
>   // brace style
>   $x = "Hello"
> |> {strtoupper($0)}
> |> { $0 . "world" }
> |> {strrev($0)};
>
>   // fn style
>   $x = "Hello"
> |> fn($x) => strtoupper($x)}
> |> fn($x) => $x . "world"
> |> fn($x) => strrev($0);
>
>   // caret style
>   $x = "Hello"
> |> ^($x) => strtoupper($x)}
> |> ^($x) => $x . "world"
> |> ^($x) => strrev($0);
>
> I included these two styles because they are the most promising versions
> from the arrow functions discussions. I think my preferred order is the one
> I wrote them in. The brace style is concise, nicely delimits the
> expression, and seems the clearest for me to read because the symbols don't
> dominate. The fn style seems nicer than caret which has too many symbols in
> close proximity for my taste.
>
> Community thoughts? Which short closure style pairs the nicest with the
> pipe operator?
>



-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] Contravariance and the "empty type"

[Michał Brzuchalski]

; >>
> >> What would be the syntax / notation for such a projected hypothetical
> >> subtype?
> >> I don't know. Let's say INTERSECT_CHILDREN
> >>
> >> So, would the following work?
> >>
> >> interface Food {..}
> >> interface Fruit extends Food {..}
> >> interface Banana extends Fruit {..}
> >>
> >> interface AbstractFoodEater {
> >>   function eat(INTERSECT_CHILDREN $food);
> >> }
> >>
> >> interface AbstractFruitEater extends AbstractFoodEater {
> >>   function eat(INTERSECT_CHILDREN $fruit);
> >> }
> >>
> >> interface BananaEater extends AbstractFruitEater {
> >>   function eat(Banana $banana);
> >> }
> >>
> >> I'm not sure.
> >> Liskov would not care. Both AbstractFoodEater and AbstractFruitEater
> >> are useless on their own.
> >> Maybe there are other logical conflicts which I don't see.
> >>
> >>
> >> --
> >>
> >> Obviously with generics this base interface would no longer be relevant.
> >> https://wiki.php.net/rfc/generics
> >>
> >> interface FruitEater {
> >>   function eat(FruitType $fruit);
> >> }
> >>
> >> // This is not really necessary.
> >> interface BananaEater extends FruitEater {
> >>   function eat(Banana $banana);
> >> }
> >>
> >> So, would the "empty type" become obsolete? Maybe.
> >> I did not arrive at a final conclusion yet. It still seems too
> >> interesting to let it go.
> >>
> >> -- Andreas
> >
> >
> > What's the purpose of this construction? I get the general idea (work
> around
> > LSP variance restrictions without generics), but I don't see how the
> > practical use would look like.
>
> To be honest I am still not fully convinced myself.
> I just couldn't resist because this idea was haunting me for too long.
>
> > After all, using the empty type as an
> > argument implies that the method may not ever be called, so wouldn't an
> > interface using it be essentially useless?
> >
> > Nikita
>
> Interfaces like AbstractFruitEater would mainly be used to categorize
> its child interfaces, and as a formalized constraint on method
> ::eat().
>
> Any child interface of AbstractFruitEater must have a method eat(),
> which must have exactly one required parameter (and as many optional
> parameters as it wants). This parameter must have a type hint
> compatible with the constraint mentioned above (in case of EMPTY_TYPE,
> there is no constraint on the parameter type, it could as well be
> "mixed").
>
> Any component that wants to call $eater->eat($apple) on an $eater of
> type AbstractFruitEater, needs to do one of two things first:
> - Use reflection to check for the first parameter's type, if it allows
> Apple.
> - Use instanceof to check if it implements AppleEater.
>
> If the $eater was only type-hinted as "object" instead of
> AbstractFruitEater, the reflection would have to do more work. It
> would have to check if a method eat() exists, and then check the first
> parameter's type.
>
> A component I might have built with the EMPTY_TYPE or with
> INTERSECT_CHILDREN would be something like this:
>
>
> // Base interface for eaters that only eat a specific fruit type.
> interface AbstractSpecificFruitEater {
>   function eat(INTERSECT_CHILDREN $fruit);
> }
>
> // Interface for eaters that eat any fruit.
> // This could extend AbstractSpecificFruitEater, but doesn't have to.
> interface FruitEater /* extends AbstractSpecificFruitEater */ {
>   function eat(Fruit $fruit);
> }
>
> class ChainedFruitEater implements FruitEater {
>   private $eaters = [];
>   public function addSpecificEater(AbstractSpecificFruitEater $eater) {
> $paramClass = (new
> \ReflectionObject($eater))->getMethod('eat')->
> getParameters()[0]->getClass();
> $this->eaters[$paramClass] = $eater;
>   }
>   public function eat(Fruit $fruit) {
> if (null !== $specificEater = $this->findSuitableEater($fruit)) {
>   $specificEater->eat($fruit);
>   return true;
> }
> else {
>   return false;
> }
>   }
>   private function findSuitableEater(Fruit $fruit) {
> foreach ($this->eaters as $paramClass => $eater) {
>   if ($fruit instanceof $paramClass) {
> return $eater;
>   }
> }
>   }
> }
>
>
> Without the EMPTY_TYPE or INTERSECT_CHILDREN, the interface
> AbstractSpecificFruitEater could not define a method ::eat().
>
> Classes implementing AbstractSpecificFruitEater would not know that a
> method ::eat() is required, and what structure it must have.
>
> The reflection line would need to check if the method exists, if the
> method is public and non-static, if the parameter exists, if it has a
> type hint class.
>
>
> In the end I implemented this another way.
> My specific fruit eaters now always accept any fruit, but do an
> instanceof check inside. They have an added method like
> "acceptsFruitClass($class)".
>
> I don't know if I would replace my current implementation with the code
> above.
> I think I rather wait for generics.
>
>
> NOTE: When I say "type hint", I do not distinguish what is currently
> implemented natively, what is in the @param PhpDoc, and what might be
> implemented natively in the future. E.g. I don't even know if "mixed"
> or "object" is currently implemented or not in latest PHP 7.
>
>
"object" type hint and return type is a part of current 7.2 release,
"mixed" not


> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] New functions: string_starts_with(), string_ends_with()

[Michał Brzuchalski]

Hi Andreas,

2017-08-01 6:57 GMT+02:00 Andreas Hennings <andr...@dqxtech.net>:

> Hello list,
> a quite common use case is that one needs to find out if a string
> $haystack begins or ends with another string $needle.
> Or in other words, if $needle is a prefix or a suffix of $haystack.
>
> One prominent example would be in PSR-4 or PSR-0 class loaders.
> Maybe the use case also occurs when writing parsers..
> In each of these two examples (parsers, class loaders), we care about
> performance.
>
> (forgive me if this was discussed before, I did not find it anywhere
> in the archives)
>
> --
>
> Existing solutions to this problem feel non-trivial, and/or are
> suboptimal in performance.
> https://stackoverflow.com/questions/2790899/how-to-
> check-if-a-string-starts-with-a-specified-string
> https://stackoverflow.com/questions/834303/startswith-
> and-endswith-functions-in-php
> This answer compares different solutions,
> https://stackoverflow.com/a/7168986/246724
>
> Existing solutions:
> (Let's focus on string_starts_with(), the other case is mostly
> equivalent / symmetric)
>
> if (0 === strpos($haystack, $needle)) {..}
> I have often seen this presented as the preferable solution.
> Unfortunately, this searches the entire string, not just the
> beginning. Especially if $haystack is really long, this can be a
> waste.
> E.g. if (0 === strpos(file_get_contents('some_source_file.php'),
> ' '
> if ($needle === substr($haystack, 0, strlen($needle))) {..}
> This reserves new memory for the substring, which later needs to be
> garbage-collected.
> Also, this requires an additional function call to strlen() - which
> adds even more clutter if $needle is an expression, not just a
> variable.
>
> if (0 === strncmp($haystack, $needle, strlen($needle))) {..}
> Needs the additional call to strlen().
> Otherwise, this seems like a really good solution.
>
> if ('' === $needle || false !== strrpos($haystack, $needle,
> -strlen($haystack))) {..}
> This is the funky solution from https://stackoverflow.com/a/
> 10473026/246724
> The author says that it will be outperformed by strncmp() - so..
>
> if (preg_match('/^' . preg_quote($needle, '/') . '/', $haystack)) {..}
> Clearly gonna be slower than other options.
>
> As said, all these solutions do work, but they are either suboptimal,
> or they add clutter and overhead, or feel a bit like mind acrobatics.
>
> -
>
> So, I wonder if it would be worthwhile to add new functions
> string_starts_with() / string_has_prefix(), and string_ends_with() /
> string_has_suffix().
>
> (Or maybe change strncmp(), so that the 3rd parameter $len is
> optional. If $len is NULL / not provided, it would use the length of
> the second (or first?) string.
> (idea was that second parameter = needle).)
>
> For me personally, I am sure that I would use a new
> string_starts_with() a lot more often than a lot of the other existing
> string functions.
> I don't think it is an exotic or niche use case.
>
> --
>
> Spinning this further:
> A lot of times if I want to check if $haystack begins with $needle, I
> will then need the rest of the string after $needle.
> So
> if (string_starts_with($haystack, $needle)) {
> $suffix = substr($haystack, strlen($needle));
> }
> or
> if (string_ends_with($filename, '.php')) {
> $basename = substr($filename, 0, -4);
> }
>
> I wonder if this could be somehow combined.
> E.g.
> if (FALSE !== $basename = string_clip_suffix($filename, '.php')) {
> // Do something with $basename.
> }
>
> --
>
> One flaw of these new functions would be that they are less versatile
> than other string functions.
> They solve this problem, and nothing else.
> On the other hand, this is the point, to avoid unnecessary overhead.
>
> The other problem would be, of course, "feature creep" aka "we have so
> many string functions already".
> This is a matter of opinion.
> I would imagine the "cost" of new native functions is:
> - global namespace pollution
> - increased mental load to learn and remember all of them
> - higher memory footprint of php engine?
> - more C code to maintain
> - a new doc page.
> Did I miss something?
>
> --
>
> -- Andreas
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
This idea was discussed 11 months ago https://externals.io/message/94787
There is also a proper RFC
https://wiki.php.net/rfc/add_str_begin_and_end_functions
You might wanna contact with Will to get feedback from the idea.

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] http_cookie_set and http_cookie_remove

[Michał Brzuchalski]

Hi Michael,

2017-07-18 21:02 GMT+02:00 Michael Morris <tendo...@gmail.com>:

> On Tue, Jul 18, 2017 at 2:56 PM, li...@rhsoft.net <li...@rhsoft.net>
> wrote:
>
> >
> >
> > Am 18.07.2017 um 20:39 schrieb Michael Morris:
> >
> >> Personally, I no longer directly use these calls, preferring instead to
> >> use
> >> Symfony's HTTP foundation classes. Those in turn are, I understand, in
> the
> >> process of being converted to implement the common interface outlined
> >> here:
> >> http://www.php-fig.org/psr/psr-7/  I would be much more interested in
> >> seeing a bare bones implementation of that agreed on standard in the
> >> language core then seeing something entirely new, especially a band aid
> >> solution
> >>
> >
> > but why do you do this?
> >
> >
> Because I want to be done in a matter of hours or at most days instead of a
> matter of weeks or months. I've been down the "roll your own" road many
> times. It usually isn't worth it.
>

You can do what you want, but personally, I think introducing this little
feature and cleaning some std API
is better than providing a more complex way of handling requests like
linked PSR-7 not everyone may want to use it.
There is always a way to use functional API in user-land PSR-7
implementation but not the other way.
IMHO if someone wants to use simple functional API let them use it, it may
also be used in more complex problem solutions.

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] http_cookie_set and http_cookie_remove

[Michał Brzuchalski]

Hi Andreas,

2017-07-18 18:39 GMT+02:00 Andreas Treichel <gmb...@gmail.com>:

> Hello Andrey,
>
> $options are equal to the optional parameters of setcookie and
>>> setrawcookie.
>>> $options may contain:
>>>
>>> expires: int
>>> path: string
>>> domain: string
>>> secure: bool
>>> httponly: bool
>>>
>>
> 1. The wording here implies that these are the *only* attributes
>> allowed. In the interest of forward-compatibility, I'd allow arbitrary
>> attributes as well.
>>
>
> This are the only supported options in the current implementation. Future
> extension like samesite cookies can add more options. Unknown options are
> ignored and trigger a warning.
>
>
> encode is an additional option to remove the requirement of a raw and non
>>> raw function.
>>>
>>> encode: int
>>> HTTP_COOKIE_ENCODE_NONE (same as setrawcookie)
>>> HTTP_COOKIE_ENCODE_RFC1738 (same as setcookie)
>>> HTTP_COOKIE_ENCODE_RFC3986
>>>
>>
> 2. I don't think this is necessary, nor that it belongs in the $options
>> array.
>>
>
> Most users dont know the correct encoding for cookies. This idea is from
> the $enc_type parameter of http://php.net/http_build_query. The
> documentation of http_cookie_set() should explain it the same way.
>
> Maybe i can move it out of the $options array and add an extra parameter
> for the encoding, if the $options are the wrong location for this.
>
>
> Anybody who'd use it, would have to read RFC1738 and/or RFC3986 to
>> know what they do.
>>
>
> This is the same as setcookie(). No one has to read the rfc, which is not
> interested as it exactly works. HTTP_COOKIE_ENCODE_RFC1738 is the default
> for the encode option and encode the value the same ways as setcookie
> encode it.
>
> the default values for the options are the same as thr parameters for the
> current setcookie(). The default values for the $options:
>
> expires: int, default: 0
> path: string, default: ""
> domain: string, default: ""
> secure: bool, default: false
> httponly: bool, default: false
> encode: int, default: HTTP_COOKIE_ENCODE_RFC1738
>
>
> And as the constant names aren't particularly short either, it is
>> easier for me to just apply an encoding function directly to $value
>> before passing it.
>>
>
> The current names of the constants are not short, but in most cases i
> think you dont need it.
>
>
> Also, RFC 6265 (section 4.1.1) only mentions Base64 as a suggestion
>> for encoding (and that's a SHOULD).
>> Link: https://tools.ietf.org/html/rfc6265#section-4.1.1
>>
>
> http_cookie_set() use the same encoding per default as setcookie().
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

As an average developer, I see providing new functions with http_ prefix
more meaningful and their API more simple because of fewer parameters I
need to pass.
Although however, I see the naming convention you've used is rarely used.
Looking in the docs, there are few other HTTP sapi related functions which
don't follow that convention, like:
header() - Send a raw HTTP header
header_remove() - Remove previously set headers
header_register_callback() - Call a header function
headers_sent() - Checks if or where headers have been sent - this function
uses referencing for retrieving the file name and line number :/ ug...
headers_list() - Returns a list of response headers sent (or ready to send)
http_response_code() - Get or Set the HTTP response code - which is THE
ONLY ONE function prefixed this way

I just wanted to pay attention to a different naming convention which
actually exists in language, which may need to be taken as a pursuit for
all HTTP related functions.
I like http_ prefixed functions because they point HTTP related nature and
I think it may clear a little bit language API.

P.S. headers_list() may be used to retrieve all headers which are sent (or
ready to send) so you might consider introducing http_cookies_list() to
retrieve all set (and not removed) cookies in current request lifecycle.


Cheers,
-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] array coalesce operator concept

[Michał Brzuchalski]

2017-07-12 22:14 GMT+02:00 Niklas Keller <m...@kelunik.com>:

> 2017-07-12 17:26 GMT+02:00 Michał Brzuchalski <
> michal.brzuchal...@gmail.com>:
>
>> 12.07.2017 15:35 "Mark Shust" <m...@shust.com> napisał(a):
>> >
>> > Hi Aidan,
>> >
>> > I think you are correct on all points. The initial emit is just a
>> warning,
>> > so I think a suppressor will work just fine, since it does just pass
>> over
>> > the foreach if a traversable isn't passed in.
>> >
>> > I could see this being helpful as it makes wrapping an if block around a
>> > foreach not needed anymore (and in turn indenting the foreach another
>> > level), replacing it with just a single character. I also think for
>> those
>> > that use linting tools and flag error suppressions, that an @as
>> definition
>> > could be easily ignored from such a linter. I develop with warnings on,
>> and
>> > see error suppressions as a sort of code smell, however I think the @as
>> > definition could be really useful.
>>
>> IMHO the whole error supression and its operator should be deprecated and
>> removed from language. Supressing errors is just hiding problems because
>> someone didn't want to solve it. Supressing errors makes debuging very
>> hard
>> and leads to frustration.
>
>
> You have to update a whole lot of APIs before you can do that. There are
> many things where it's better to ignore the warning and check the return
> value and throw an exception if something is wrong.
>
> Regards, Niklas
>
>
Hi Niklas,

could you name few of them?
My ideal vision is catching thrown exceptions instead of suppressing errors.
BTW it would unlock '@' for future features like use for
annotations/attributes.

Regards,
--
Michał Brzuchalski