Re: [PHP-DEV] Re: [RFC] "arrayable" pseudo type hint

[Andreas Hennings]

On Tue, 4 Feb 2020 at 22:19, Larry Garfield  wrote:

> On Tue, Feb 4, 2020, at 12:40 PM, Aimeos | Norbert Sendetzky wrote:
> > Am 04.02.20 um 19:17 schrieb Rowan Tommins:
> > > I think Larry's point was that the flexibility of PHP's array type
> makes it
> > > really hard to pin down whether a given object is "array-like" or not,
> and
> > > which attributes a particular function actually cares about.
> >
> > What else besides array access, counting and traversing is possible that
> > may differ from classes that implement those interfaces?
> >
> > > A general "intersection type" system might be more useful, because
> then you
> > > could require the parts you specifically needed, such as
> > > "traversable" or "traversable".
> >
> > I think that's too complicated and we should make it as easy as possible
> > for PHP developers.
> >
> > Also, there's already an RFC for intersection types but it was never
> > adopted: https://wiki.php.net/rfc/intersection_types
>
>
> Rowan is exactly right and said it better than I did.
>
> The point is that "I can count() it", "I can foreach() it" and "I can
> bracket it" are three different things; in practice, a given function
> likely only cares about one, maybe two of those at a time.  Adding a type
> for "an object that mimics all of the dumb things arrays do, but now passes
> differently" doesn't strike me as useful; it strikes me as the sort of
> thing I'd reject in a code review if someone tried to do it in user space.
>
> The problem with PHP arrays is that they're not arrays; they're a hash map
> with poor safety, lame error semantics, and some cheats to make them kinda
> sorta look like arrays if you don't look too carefully.  In practice, they
> create more bugs than they fix.
>

There is one good thing about arrays:
They are passed along by-value by default, which gives them similar
qualities as an "immutable" object.
If you pass an array to a function as a parameter which is not
by-reference, you can expect the original array to remain unchanged.
(Objects or referenced variables within that array can still be modified of
course)

A function parameter which allows an object OR an array loses this
advantage.

If I have the choice between \stdClass and array for "unstructured tree of
data", I will always prefer the array.

~~ Andreas


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

Re: [PHP-DEV] Re: [RFC] "arrayable" pseudo type hint

[Larry Garfield]

On Tue, Feb 4, 2020, at 12:40 PM, Aimeos | Norbert Sendetzky wrote:
> Am 04.02.20 um 19:17 schrieb Rowan Tommins:
> > I think Larry's point was that the flexibility of PHP's array type makes it
> > really hard to pin down whether a given object is "array-like" or not, and
> > which attributes a particular function actually cares about.
> 
> What else besides array access, counting and traversing is possible that
> may differ from classes that implement those interfaces?
> 
> > A general "intersection type" system might be more useful, because then you
> > could require the parts you specifically needed, such as
> > "traversable" or "traversable".
> 
> I think that's too complicated and we should make it as easy as possible
> for PHP developers.
> 
> Also, there's already an RFC for intersection types but it was never
> adopted: https://wiki.php.net/rfc/intersection_types


Rowan is exactly right and said it better than I did.

The point is that "I can count() it", "I can foreach() it" and "I can bracket 
it" are three different things; in practice, a given function likely only cares 
about one, maybe two of those at a time.  Adding a type for "an object that 
mimics all of the dumb things arrays do, but now passes differently" doesn't 
strike me as useful; it strikes me as the sort of thing I'd reject in a code 
review if someone tried to do it in user space.

The problem with PHP arrays is that they're not arrays; they're a hash map with 
poor safety, lame error semantics, and some cheats to make them kinda sorta 
look like arrays if you don't look too carefully.  In practice, they create 
more bugs than they fix.

Intersection types would be absolutely delightful and I want them for numerous 
reasons.

--Larry Garfield

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

Re: [PHP-DEV] Re: [RFC] "arrayable" pseudo type hint

[Guilliam Xavier]

On Tue, Feb 4, 2020 at 1:48 PM Aimeos | Norbert Sendetzky
 wrote:
>
> [...]
>
> interface Arrayable extends ArrayAccess, Countable, Traversable
> {
> public function toArray() : array;
> }
>
> [...]
>
> If union data types are available and "iterable" is implemented as
> alias, an alias "arrayable" for "array|Arrayable" may be added as well.

About that last point: it would not be possible to have both the
`Arrayable` interface and the `arrayable` reserved word because PHP is
case-insensitive for those things (the same way you cannot declare an
`interface Iterable` because of the `iterable` reserved word,
), so you would need another name (if you want
the alias)

-- 
Guilliam Xavier

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

Re: [PHP-DEV] Re: [RFC] "arrayable" pseudo type hint

[Aimeos | Norbert Sendetzky]

Am 04.02.20 um 19:17 schrieb Rowan Tommins:
> I think Larry's point was that the flexibility of PHP's array type makes it
> really hard to pin down whether a given object is "array-like" or not, and
> which attributes a particular function actually cares about.

What else besides array access, counting and traversing is possible that
may differ from classes that implement those interfaces?

> A general "intersection type" system might be more useful, because then you
> could require the parts you specifically needed, such as
> "traversable" or "traversable".

I think that's too complicated and we should make it as easy as possible
for PHP developers.

Also, there's already an RFC for intersection types but it was never
adopted: https://wiki.php.net/rfc/intersection_types

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

Re: [PHP-DEV] Re: [RFC] "arrayable" pseudo type hint

[Rowan Tommins]

On Tue, 4 Feb 2020 at 18:06, Aimeos | Norbert Sendetzky 
wrote:

> Am 04.02.20 um 18:18 schrieb Larry Garfield:
> > The more I think on it, the less I like `arrayable`.  PHP arrays are
> > a terrible data structure from a type system point of view, with too
> > much functionality crammed into one variable type.
>
> The array internals are outside the scope of this proposal and are not
> affected in any way by this proposal.
>


I think Larry's point was that the flexibility of PHP's array type makes it
really hard to pin down whether a given object is "array-like" or not, and
which attributes a particular function actually cares about.

A general "intersection type" system might be more useful, because then you
could require the parts you specifically needed, such as
"traversable" or "traversable".

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] Re: [RFC] "arrayable" pseudo type hint

[Aimeos | Norbert Sendetzky]

Am 04.02.20 um 18:18 schrieb Larry Garfield:
>> interface Arrayable extends ArrayAccess, Countable, Traversable
>> {
>> public function toArray() : array;
>> }
>>
>> Then, methods signatures can support array and Array-like objects:
>>
>> function useArrayable( array|Arrayable $arg ) : array|Arrayable {
>> $cnt = count( $arg );
>> $value = $arg['key'];
>> foreach( $arg as $key => $entry );
>> is_object( $arg ) { $nativeArray = $arg->toArray(); }
>> return $arg;
>> }
>> 
>> If union data types are available and "iterable" is implemented as 
>> alias, an alias "arrayable" for "array|Arrayable" may be added as
>> well.
> 
> The more I think on it, the less I like `arrayable`.  PHP arrays are
> a terrible data structure from a type system point of view, with too
> much functionality crammed into one variable type.

The array internals are outside the scope of this proposal and are not
affected in any way by this proposal.

> If you want an object that shoves all the various bits of arrayness
> into one object, there's already ArrayObject, which you can extend if
> desired.

Tried that already, but other core developers made very clear that
ArrayObject is one of the worst implementations in PHP and that it's not
going to be improved or touched in any way and using it is highly
discouraged.

> Especially with union types, amalgam built in types like this are
> even less needed.

If an "arrayable" pseudo type should be implemented is subject to
discussion. It would be a short form for "array|Arrayable" (native type
or interface for array like objects) only offering a syntactical sugar
for developers.

> Aside from iterable, the only other built-in alias I would see is one
> for array|ArrayAccess.  But... it's now possible to do exactly like
> that, so I don't know how useful it would be.

"array|ArrayAccess" is not sufficient because arrays are also countable
and traversable and this isn't possible with union data types:

interface Arrayable extends ArrayAccess, Countable, Traversable

function useArrayable( array|Arrayable $arg ) {
$cnt = count( $arg );
$value = $arg['key'];
foreach( $arg as $key => $entry );
}

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

Re: [PHP-DEV] Re: [RFC] "arrayable" pseudo type hint

[Larry Garfield]

On Tue, Feb 4, 2020, at 6:48 AM, Aimeos | Norbert Sendetzky wrote:
> I would like to modify my initial concept of an "arrayable" type because
> PHP core developers seems to be in favor of the upcoming union data
> types instead of adding a new "arrayable" pseudo type similar to "iterable".
> 
> So, I would like to propose an "Arrayable" interface that combines
> ArrayAccess, Countable and Traversable interfaces and adds a toArray()
> method:
> 
> interface Arrayable extends ArrayAccess, Countable, Traversable
> {
> public function toArray() : array;
> }
> 
> Then, methods signatures can support array and Array-like objects:
> 
> function useArrayable( array|Arrayable $arg ) : array|Arrayable {
> $cnt = count( $arg );
> $value = $arg['key'];
> foreach( $arg as $key => $entry );
> is_object( $arg ) { $nativeArray = $arg->toArray(); }
> return $arg;
> }
> 
> Adding a toArray() method also avoids controversy around using a magic
> __toArray() method, even if this would be easier for developers in this
> case.
> 
> If union data types are available and "iterable" is implemented as
> alias, an alias "arrayable" for "array|Arrayable" may be added as well.

The more I think on it, the less I like `arrayable`.  PHP arrays are a terrible 
data structure from a type system point of view, with too much functionality 
crammed into one variable type.

If you want an object that shoves all the various bits of arrayness into one 
object, there's already ArrayObject, which you can extend if desired.

Especially with union types, amalgam built in types like this are even less 
needed.

Aside from iterable, the only other built-in alias I would see is one for 
array|ArrayAccess.  But... it's now possible to do exactly like that, so I 
don't know how useful it would be.

--Larry Garfield

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

Re: [PHP-DEV] [RFC - discussion] __toArray()

[Steven Wade]

> I think the motivation is exactly what you said. Allowing developers more 
> control over how the object is treated when casted to an array - which would 
> include when it is passed into an array_* function.

I couldn’t (and didn’t) have said it better myself. My motivation is really 
just to give developers more control over their code and allow them to have 
cleaner code.

Re: [PHP-DEV] [RFC - discussion] __toArray()

[Chase Peeler]

On Tue, Feb 4, 2020 at 11:04 AM Steven Wade  wrote:

>
> > Sorry if it's been said in the discussion so far, but I do not see why
> > `print_r` should convert anything to an array. It accepts multiple
> > kinds of types including strings, numbers, and so on, and I think
> > adding this behavior to `print_r` is a different thing than wanting a
> > standard way for objects to be converted into arrays.
>
> You’re right, that’s my bad. I swore I tested print_r() with a class and
> __toString() and it cast it, but I just ran it again and it just outputs
> the object. The goal would be to have __toArray() behave on arrays like
> __toString() does on strings. I’ll update the RFC to remove the reference
> to print_r(). Thanks!
>
>
> > And on that note, what is the motivation for wanting a magic method
> > for converting an object into an array? Why not make it an explicit
> > operation? I do not see the point of the magic here, except _maybe_
> > for adding it to `ArrayObject` or something to allow it to work with
> > the array_* functions that work without references, in which case I
> > think we think this RFC is the wrong approach as it is inadequate for
> > that purpose.
>
> I think the motivation is exactly what you said. Allowing developers more
control over how the object is treated when casted to an array - which
would include when it is passed into an array_* function.

Here is a use-case:
if(is_object($arrayOrObject)){
  $a = array_map($callback,$arrayOrObject->toArray());
} else {
 $a = array_map($callback,$arrayOrObject);
}

becomes

$a = array_map($callback,$arrayOrObject);

I'm not making an argument one way or the other for whether the above is
justification, but, it does at least allow the above simplification of code.


> PHP’s pretty magical already, so adding another magic method isn’t out of
> the question and would keep things inline with how some things are done
> already. The idea for having magical casting is to make it simpler in the
> user land for general array behavior when reading or looping.
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC - discussion] __toArray()

[Steven Wade]

> Sorry if it's been said in the discussion so far, but I do not see why
> `print_r` should convert anything to an array. It accepts multiple
> kinds of types including strings, numbers, and so on, and I think
> adding this behavior to `print_r` is a different thing than wanting a
> standard way for objects to be converted into arrays.

You’re right, that’s my bad. I swore I tested print_r() with a class and 
__toString() and it cast it, but I just ran it again and it just outputs the 
object. The goal would be to have __toArray() behave on arrays like 
__toString() does on strings. I’ll update the RFC to remove the reference to 
print_r(). Thanks!


> And on that note, what is the motivation for wanting a magic method
> for converting an object into an array? Why not make it an explicit
> operation? I do not see the point of the magic here, except _maybe_
> for adding it to `ArrayObject` or something to allow it to work with
> the array_* functions that work without references, in which case I
> think we think this RFC is the wrong approach as it is inadequate for
> that purpose.

PHP’s pretty magical already, so adding another magic method isn’t out of the 
question and would keep things inline with how some things are done already. 
The idea for having magical casting is to make it simpler in the user land for 
general array behavior when reading or looping.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Add viable long running execution model to php 8

[Robert Hickman]

On Wed, 29 Jan 2020, 7:42 pm Peter Bowyer, 
wrote:

> On Tue, 28 Jan 2020 at 17:12, Rowan Tommins 
> wrote:
>
> > I'd just like to point out that those two things are orthogonal: the fact
> > that Swoole is distributed as an extension is not the reason it's
> > incompatible with your existing code, and building a similar
> implementation
> > into PHP under a different name wouldn't make the migration any easier.
> >
>
> You're absolutely right. The difference I'm thinking is that if there is
> built-in support in the language, frameworks will embrace it. At the moment
> I'd need to make my own fork to add compatibility with Swoole et al (or use
> one of the experimental but unsupported forks out there), which isn't
> attractive.
>

This was why i raised the issue. If it is covered in the core more people
are going to use it. It would be espesially good if it could be supported
within the shared hosting settings where php is commonly used.

As swoole etc have allready done good work, would it make sense to adopt
one of these as official?

>

Re: [PHP-DEV] [RFC - discussion] __toArray()

[Levi Morrison via internals]

Sorry if it's been said in the discussion so far, but I do not see why
`print_r` should convert anything to an array. It accepts multiple
kinds of types including strings, numbers, and so on, and I think
adding this behavior to `print_r` is a different thing than wanting a
standard way for objects to be converted into arrays.

And on that note, what is the motivation for wanting a magic method
for converting an object into an array? Why not make it an explicit
operation? I do not see the point of the magic here, except _maybe_
for adding it to `ArrayObject` or something to allow it to work with
the array_* functions that work without references, in which case I
think we think this RFC is the wrong approach as it is inadequate for
that purpose.

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

Re: [PHP-DEV] Re: Moving the documentation to git

[Nikita Popov]

On Tue, Feb 4, 2020 at 3:55 PM Andreas Heigl  wrote:

> Hey Nikita.
>
> Am 04.02.20 um 15:49 schrieb Nikita Popov:
> > On Tue, Feb 4, 2020 at 3:46 PM Andreas Heigl  wrote:
> >
> >> Hey Nikita.
> >>
> >> Am 04.02.20 um 15:20 schrieb Nikita Popov:
> >>> On Tue, Feb 4, 2020 at 2:08 PM Nikita Popov 
> >> wrote:
> >>>
>  On Tue, Feb 4, 2020 at 1:48 PM Andreas Heigl 
> wrote:
> 
> > Hey Nikita, hey all.
> >
> > Am 04.02.20 um 12:11 schrieb Nikita Popov:
> >> On Tue, Feb 4, 2020 at 8:09 AM Andreas Heigl  >> > wrote:
> >
> >>
> >> Hi Andreas,
> >>
> >> would you mind pushing the current en/de repos to
> >> https://github.com/phpdoctest/en and de so it's possible to see how
> > they
> >> look like now?
> >
> > Find the repos (as they should be on git.php.net would I have
> access)
> >> at
> > https://github.com/phpdoctest/de and
> https://github.com/phpdoctest/en
> >
> > They are updated after each run of the converter-tool which currently
> > runs every two hours.
> >
> 
>  Thanks! It looks like currently the author mapping from svn -> git is
>  missing, which also means we don't get the mapping to github accounts.
> >> I'll
>  send you the author mapping file I have (which  is unfortunately
> >> somewhat
>  dated, maybe Peter has a newer one?), it would be great to preserve
>  authorship in a meaningful way.
> 
>  Nikita
> 
> >>>
> >>> In a previous mail you mentioned that the current EN-Revision is now
> >> being
> >>> tracked in a separate file. Could you point out which files that is,
> >>> because I didn't see it in the repo. Or is it part of some other repo?
> >>
> >> The en-revision is tracked in the translated repos only, not in the
> >> english one.
> >>
> >> Have a look at
> >> https://github.com/phpdoctest/de/blob/master/.en-revisions.ref
> >
> >
> > Thanks! I think what confused me is that the last commit to the repo (
> >
> https://github.com/phpdoctest/de/commit/10286e6f55405503cecfeae2e91fa030a57a5906
> )
> > modifies an EN-Revision in a file, but there is no corresponding update
> to
> > .en-revisions.ref. Shouldn't there be one?
>
> There should be one and I have noticed that as well. I will need to redo
> the steps anyhow this weekend to add the correct authors-file and will
> then also have a look at why that is not updated accordingly. Do you
> know which file that update was in?
>

Sorry, not sure what you mean by "which file" here.


> >
> > PS: I have done "Step 1" and created all the necessary repositories in
> > git.php.net.
>
> Awesome! Thank you! Who has commit access to that repo so far? I would
> then start pushing the data as soon as I have fixed the authors list. At
> least to the translations.


I have granted you access to the new repositories (force push should also
work -- we don't disable that by default). That is everything apart from
doc/base, doc/en and doc/de, because Peter is currently mirroring those.
You'll have to coordinate with him to avoid two different mirroring setups
overwriting each other.


> @salathe, shall I also force-push to the
> neglish master-branch or shall I push to a different branch in the en-repo?
>

Once the author list is fixed, are those repositories actually going to
differ in any way? As far as I understood, only the translation repos are
changed. Assuming your mirroring methodology is the same, I would expect
you to arrive at the same doc-en repo.

Nikita

Re: [PHP-DEV] [RFC - discussion] __toArray()

[Chase Peeler]

On Tue, Feb 4, 2020 at 9:23 AM Marco Pivetta  wrote:

> On Tue, Feb 4, 2020, 14:50 Aimeos | Norbert Sendetzky 
> wrote:
>
> > Am 04.02.20 um 14:43 schrieb Marco Pivetta:
> > >> I think we can't classify it as BC break, because no existing code
> > >> implements __toArray at the moment, and hence it will not fail when
> this
> > >> feature is introduced and code gets upgraded to newer versions.
> > >
> > > It is a BC break because it changes the semantic of `(array) $object`:
> > the
> > > operation is no longer stable between two versions of the language.
> >
> > It wouldn't be a BC breaking change if `(array) $object` works like
> > before when __toArray() isn't implemented by an object. As nobody should
> > have implemented __toArray() because it's a reserved name for magic
> > methods, we should be fine.
> >
>
> The operation in question, when seen by its signature, is:
>
> (array) :: object FieldTypes -> Map String FieldTypes
>
> The proposed RFC changes this to (pardon the weird union type: my type-fu
> is not that advanced):
>
> (array) :: (FieldTypes|IO ToArrayTypes a) => object a -> Map String a
>
> This changes the return type of a very much pure function (even makes it
> non-pure: fun), and is a very, very, very clear BC break.
>
> >
>
I think we all know that I'm very big on avoiding BC breaks. I personally
don't see this as a BC break, though. At least not one with PHP.

Right now, behavior when casting things to an array is like so:
(array)$scalar ==> [$scalar]
(array)$array ==> $array
(array)$object ==> [$prop1=>$val1, $prop2=>$val2, ...]

So, assuming that right now I have the code:
$x = new SomeThirdPartyArrayLikeObject();
//stuff
$y = (array)$x;
//$y ==> [$prop1=>$val1, $prop2 => $val2, ...]

In a future version, in order to make that library more array-like, the
following is added:
public function __toArray(){
   return [$this];
}

Based on that, I'd argue that the BC break is with the library, not PHP. If
the __toArray function is not implemented on that class, then nothing
changes. The only way you'd get BC breaks with PHP itself is if core (and,
arguably extension) classes started behaving differently when cast to an
array.

I'm personally in favor of anything that is going to allow us to create
array-like objects that can be treated like arrays. I personally hate
having to write:

if(is_object($var)){
  $x = [$var];
} else {
  $x = (array)$var;
}

No, the other question is whether we do it with a magic method, like
__toArray() or an interface. I personally like magic methods, but, in the
end I'm ambivalent on that.

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Re: Moving the documentation to git

[Andreas Heigl]

Hey Nikita.

Am 04.02.20 um 15:49 schrieb Nikita Popov:
> On Tue, Feb 4, 2020 at 3:46 PM Andreas Heigl  wrote:
> 
>> Hey Nikita.
>>
>> Am 04.02.20 um 15:20 schrieb Nikita Popov:
>>> On Tue, Feb 4, 2020 at 2:08 PM Nikita Popov 
>> wrote:
>>>
 On Tue, Feb 4, 2020 at 1:48 PM Andreas Heigl  wrote:

> Hey Nikita, hey all.
>
> Am 04.02.20 um 12:11 schrieb Nikita Popov:
>> On Tue, Feb 4, 2020 at 8:09 AM Andreas Heigl > > wrote:
>
>>
>> Hi Andreas,
>>
>> would you mind pushing the current en/de repos to
>> https://github.com/phpdoctest/en and de so it's possible to see how
> they
>> look like now?
>
> Find the repos (as they should be on git.php.net would I have access)
>> at
> https://github.com/phpdoctest/de and https://github.com/phpdoctest/en
>
> They are updated after each run of the converter-tool which currently
> runs every two hours.
>

 Thanks! It looks like currently the author mapping from svn -> git is
 missing, which also means we don't get the mapping to github accounts.
>> I'll
 send you the author mapping file I have (which  is unfortunately
>> somewhat
 dated, maybe Peter has a newer one?), it would be great to preserve
 authorship in a meaningful way.

 Nikita

>>>
>>> In a previous mail you mentioned that the current EN-Revision is now
>> being
>>> tracked in a separate file. Could you point out which files that is,
>>> because I didn't see it in the repo. Or is it part of some other repo?
>>
>> The en-revision is tracked in the translated repos only, not in the
>> english one.
>>
>> Have a look at
>> https://github.com/phpdoctest/de/blob/master/.en-revisions.ref
> 
> 
> Thanks! I think what confused me is that the last commit to the repo (
> https://github.com/phpdoctest/de/commit/10286e6f55405503cecfeae2e91fa030a57a5906)
> modifies an EN-Revision in a file, but there is no corresponding update to
> .en-revisions.ref. Shouldn't there be one?

There should be one and I have noticed that as well. I will need to redo
the steps anyhow this weekend to add the correct authors-file and will
then also have a look at why that is not updated accordingly. Do you
know which file that update was in?
> 
> PS: I have done "Step 1" and created all the necessary repositories in
> git.php.net.

Awesome! Thank you! Who has commit access to that repo so far? I would
then start pushing the data as soon as I have fixed the authors list. At
least to the translations. @salathe, shall I also force-push to the
neglish master-branch or shall I push to a different branch in the en-repo?

Cheers

Andreas
> 
> Nikita
> 

-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Moving the documentation to git

[Nikita Popov]

On Tue, Feb 4, 2020 at 3:46 PM Andreas Heigl  wrote:

> Hey Nikita.
>
> Am 04.02.20 um 15:20 schrieb Nikita Popov:
> > On Tue, Feb 4, 2020 at 2:08 PM Nikita Popov 
> wrote:
> >
> >> On Tue, Feb 4, 2020 at 1:48 PM Andreas Heigl  wrote:
> >>
> >>> Hey Nikita, hey all.
> >>>
> >>> Am 04.02.20 um 12:11 schrieb Nikita Popov:
>  On Tue, Feb 4, 2020 at 8:09 AM Andreas Heigl   > wrote:
> >>>
> 
>  Hi Andreas,
> 
>  would you mind pushing the current en/de repos to
>  https://github.com/phpdoctest/en and de so it's possible to see how
> >>> they
>  look like now?
> >>>
> >>> Find the repos (as they should be on git.php.net would I have access)
> at
> >>> https://github.com/phpdoctest/de and https://github.com/phpdoctest/en
> >>>
> >>> They are updated after each run of the converter-tool which currently
> >>> runs every two hours.
> >>>
> >>
> >> Thanks! It looks like currently the author mapping from svn -> git is
> >> missing, which also means we don't get the mapping to github accounts.
> I'll
> >> send you the author mapping file I have (which  is unfortunately
> somewhat
> >> dated, maybe Peter has a newer one?), it would be great to preserve
> >> authorship in a meaningful way.
> >>
> >> Nikita
> >>
> >
> > In a previous mail you mentioned that the current EN-Revision is now
> being
> > tracked in a separate file. Could you point out which files that is,
> > because I didn't see it in the repo. Or is it part of some other repo?
>
> The en-revision is tracked in the translated repos only, not in the
> english one.
>
> Have a look at
> https://github.com/phpdoctest/de/blob/master/.en-revisions.ref


Thanks! I think what confused me is that the last commit to the repo (
https://github.com/phpdoctest/de/commit/10286e6f55405503cecfeae2e91fa030a57a5906)
modifies an EN-Revision in a file, but there is no corresponding update to
.en-revisions.ref. Shouldn't there be one?

PS: I have done "Step 1" and created all the necessary repositories in
git.php.net.

Nikita

Re: [PHP-DEV] Re: Moving the documentation to git

[Andreas Heigl]

Hey Nikita.

Am 04.02.20 um 15:20 schrieb Nikita Popov:
> On Tue, Feb 4, 2020 at 2:08 PM Nikita Popov  wrote:
> 
>> On Tue, Feb 4, 2020 at 1:48 PM Andreas Heigl  wrote:
>>
>>> Hey Nikita, hey all.
>>>
>>> Am 04.02.20 um 12:11 schrieb Nikita Popov:
 On Tue, Feb 4, 2020 at 8:09 AM Andreas Heigl >>> > wrote:
>>>

 Hi Andreas,

 would you mind pushing the current en/de repos to
 https://github.com/phpdoctest/en and de so it's possible to see how
>>> they
 look like now?
>>>
>>> Find the repos (as they should be on git.php.net would I have access) at
>>> https://github.com/phpdoctest/de and https://github.com/phpdoctest/en
>>>
>>> They are updated after each run of the converter-tool which currently
>>> runs every two hours.
>>>
>>
>> Thanks! It looks like currently the author mapping from svn -> git is
>> missing, which also means we don't get the mapping to github accounts. I'll
>> send you the author mapping file I have (which  is unfortunately somewhat
>> dated, maybe Peter has a newer one?), it would be great to preserve
>> authorship in a meaningful way.
>>
>> Nikita
>>
> 
> In a previous mail you mentioned that the current EN-Revision is now being
> tracked in a separate file. Could you point out which files that is,
> because I didn't see it in the repo. Or is it part of some other repo?

The en-revision is tracked in the translated repos only, not in the
english one.

Have a look at
https://github.com/phpdoctest/de/blob/master/.en-revisions.ref


Cheers

Andreas

-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC - discussion] __toArray()

[Marco Pivetta]

On Tue, Feb 4, 2020, 14:50 Aimeos | Norbert Sendetzky 
wrote:

> Am 04.02.20 um 14:43 schrieb Marco Pivetta:
> >> I think we can't classify it as BC break, because no existing code
> >> implements __toArray at the moment, and hence it will not fail when this
> >> feature is introduced and code gets upgraded to newer versions.
> >
> > It is a BC break because it changes the semantic of `(array) $object`:
> the
> > operation is no longer stable between two versions of the language.
>
> It wouldn't be a BC breaking change if `(array) $object` works like
> before when __toArray() isn't implemented by an object. As nobody should
> have implemented __toArray() because it's a reserved name for magic
> methods, we should be fine.
>

The operation in question, when seen by its signature, is:

(array) :: object FieldTypes -> Map String FieldTypes

The proposed RFC changes this to (pardon the weird union type: my type-fu
is not that advanced):

(array) :: (FieldTypes|IO ToArrayTypes a) => object a -> Map String a

This changes the return type of a very much pure function (even makes it
non-pure: fun), and is a very, very, very clear BC break.

>

[PHP-DEV] Re: Moving the documentation to git

[Nikita Popov]

On Tue, Feb 4, 2020 at 2:08 PM Nikita Popov  wrote:

> On Tue, Feb 4, 2020 at 1:48 PM Andreas Heigl  wrote:
>
>> Hey Nikita, hey all.
>>
>> Am 04.02.20 um 12:11 schrieb Nikita Popov:
>> > On Tue, Feb 4, 2020 at 8:09 AM Andreas Heigl > > > wrote:
>>
>> >
>> > Hi Andreas,
>> >
>> > would you mind pushing the current en/de repos to
>> > https://github.com/phpdoctest/en and de so it's possible to see how
>> they
>> > look like now?
>>
>> Find the repos (as they should be on git.php.net would I have access) at
>> https://github.com/phpdoctest/de and https://github.com/phpdoctest/en
>>
>> They are updated after each run of the converter-tool which currently
>> runs every two hours.
>>
>
> Thanks! It looks like currently the author mapping from svn -> git is
> missing, which also means we don't get the mapping to github accounts. I'll
> send you the author mapping file I have (which  is unfortunately somewhat
> dated, maybe Peter has a newer one?), it would be great to preserve
> authorship in a meaningful way.
>
> Nikita
>

In a previous mail you mentioned that the current EN-Revision is now being
tracked in a separate file. Could you point out which files that is,
because I didn't see it in the repo. Or is it part of some other repo?

Nikita

Re: [PHP-DEV] [RFC - discussion] __toArray()

[Benjamin Eberlei]

On Tue, Feb 4, 2020 at 2:43 PM Marco Pivetta  wrote:

>
>
> On Tue, Feb 4, 2020, 14:36 Benjamin Eberlei  wrote:
>
>>
>>
>> On Tue, Feb 4, 2020 at 2:10 PM Marco Pivetta  wrote:
>>
>>> Linking (again) previous discussions:
>>> https://externals.io/message/98539#98539
>>>
>>> `__toArray` as a magic function call when `(array)` cast happen is a bad
>>> idea: it is a BC break, and it removes one of the very few interactions
>>> (with objects) that didn't cause any side-effects (
>>> https://externals.io/message/98539#98545,
>>> https://externals.io/message/98539#98567)
>>>
>>
>> I think we can't classify it as BC break, because no existing code
>> implements __toArray at the moment, and hence it will not fail when this
>> feature is introduced and code gets upgraded to newer versions.
>>
>
> It is a BC break because it changes the semantic of `(array) $object`: the
> operation is no longer stable between two versions of the language.
>
> Code relying on `(array)` behaviour (stable) requires additional
> reflection wrappers to check if `$object` is **not** implementing
> `__toArray`, and then the operation can be safely used (or an exception is
> to be thrown).
>
> You can most certainly make a new operation, such as `(toArray) $object`:
> the cast operator is new and isn't changing any existing behaviour.
>

I believe the definition of BC break is "can an existing code-base run on
the new PHP version without changes" and here the answer is yes, since
__toArray fn's are not used by any existing code bases.

What you refer to is, can existing code work with new code using this
feature, and then the answer is indeed no. But the same was true for
example for typed properties, which also requires additional handling in
most meta programming libraries, and many other new features that existing
libraries needed to adapt to: namespaces, scalar type hints, return types,
...

Re: [PHP-DEV] [RFC - discussion] __toArray()

[Aimeos | Norbert Sendetzky]

Am 04.02.20 um 14:43 schrieb Marco Pivetta:
>> I think we can't classify it as BC break, because no existing code
>> implements __toArray at the moment, and hence it will not fail when this
>> feature is introduced and code gets upgraded to newer versions.
> 
> It is a BC break because it changes the semantic of `(array) $object`: the
> operation is no longer stable between two versions of the language.

It wouldn't be a BC breaking change if `(array) $object` works like
before when __toArray() isn't implemented by an object. As nobody should
have implemented __toArray() because it's a reserved name for magic
methods, we should be fine.

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

Re: [PHP-DEV] [RFC - discussion] __toArray()

[Steven Wade]

>> 3. The weak point of this proposal is the by reference handling for sort et 
>> al. Counterpoint: if you pass a variable to preg_match, then matches gets 
>> converted from anything to array, so i believe by reference casting should 
>> change the original value (https://3v4l.org/XUJ5m ). 
>> This is weird, but consistent.
> 
> The proposal states that “array functions that operate on an array by 
> reference such as sort or shuffle will not work on an object implementing 
> __toArray() under this proposal”, and IMO that is consistent with other 
> magical casting behaviors and I wouldn’t expect a class implementing 
> __toArray() to be able to be written or referenced like a traditional array.
> 
> Passing an object with toString by reference will change the original 
> variable: https://3v4l.org/77lov 
Ah, I think I see what you mean. PHP’s making a copy of the string variable 
once it’s cast, so it’s no longer referencing the original object that 
implemented the __toString() method. I imagined the __toArray() would function 
the same. Once the cast is called on the object, it’s a new array variable and 
can be acted upon as such. What I was trying to get at was that the magic 
method does not give the ability to write to the original object. If that’s not 
clear then I need to update the RFC.

Re: [PHP-DEV] @official_php credentials?

[Derick Rethans]

On Tue, 4 Feb 2020, Ben Ramsey wrote:

> If you use TweetDeck, you can grant access to others, without needing 
> to pass around the credentials.

Yes, that is exactly how we are using it.

cheers,
Derick

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

Re: [PHP-DEV] [RFC - discussion] __toArray()

[Marco Pivetta]

On Tue, Feb 4, 2020, 14:36 Benjamin Eberlei  wrote:

>
>
> On Tue, Feb 4, 2020 at 2:10 PM Marco Pivetta  wrote:
>
>> Linking (again) previous discussions:
>> https://externals.io/message/98539#98539
>>
>> `__toArray` as a magic function call when `(array)` cast happen is a bad
>> idea: it is a BC break, and it removes one of the very few interactions
>> (with objects) that didn't cause any side-effects (
>> https://externals.io/message/98539#98545,
>> https://externals.io/message/98539#98567)
>>
>
> I think we can't classify it as BC break, because no existing code
> implements __toArray at the moment, and hence it will not fail when this
> feature is introduced and code gets upgraded to newer versions.
>

It is a BC break because it changes the semantic of `(array) $object`: the
operation is no longer stable between two versions of the language.

Code relying on `(array)` behaviour (stable) requires additional reflection
wrappers to check if `$object` is **not** implementing `__toArray`, and
then the operation can be safely used (or an exception is to be thrown).

You can most certainly make a new operation, such as `(toArray) $object`:
the cast operator is new and isn't changing any existing behaviour.

Re: [PHP-DEV] [RFC - discussion] __toArray()

[Benjamin Eberlei]

On Tue, Feb 4, 2020 at 2:39 PM Steven Wade  wrote:

>
> I am open to the idea of having __toArray. I just have a few questions
> about the RFC details.
>
> 1. print_r($object) would somehow call __toArray you say. Why would it
> cause a cast when nothing else is cast? I would prefer print_r((array)
> $person);
>
>
> Originally I intended the proposal to be specific to user casting like you
> suggested but when writing the RFC I decided to pursue making the magic
> method and casting more in line with the behavior of __toString(). For
> example, when an object implements the __toString() method and you simply
> “echo $obj” PHP automatically casts the object for you.
>

Yes, i see that it auto casts when you typehint for "array". print_r
argument is not array but mixed, so it should not cast the object to array
there.

>
> 2. In the parameter and return type examples you should add
> declare(strict_types=0); so it's clear this only works in weak mode.
>
>
> I think this is a good idea. I hadn’t looked into strict_types and how it
> handles strings and their casting. Thanks!
>
> 3. The weak point of this proposal is the by reference handling for sort
> et al. Counterpoint: if you pass a variable to preg_match, then matches
> gets converted from anything to array, so i believe by reference casting
> should change the original value (https://3v4l.org/XUJ5m). This is weird,
> but consistent.
>
>
> The proposal states that “array functions that operate on an array by
> reference such as sort or shuffle will not work on an object
> implementing __toArray() under this proposal”, and IMO that is consistent
> with other magical casting behaviors and I wouldn’t expect a class
> implementing __toArray() to be able to be written or referenced like a
> traditional array.
>

Passing an object with toString by reference will change the original
variable: https://3v4l.org/77lov

Re: [PHP-DEV] @official_php credentials?

[Ben Ramsey]

> On Feb 4, 2020, at 04:29, Derick Rethans  wrote:
> 
> Hi,
> 
> Adam gave them to me last night, so: me.
> 
> cheers,
> Derick
> 
> 
>> On Tue, 4 Feb 2020, Nikita Popov wrote:
>> 
>> Hi,
>> 
>> Does anyone know the credentials for the @official_php Twitter account?
>> None of the releases since November last year (including 7.4.0) have been
>> announced.
>> 
>> Regards,
>> Nikita


If you use TweetDeck, you can grant access to others, without needing to pass 
around the credentials.

-Ben

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

Re: [PHP-DEV] [RFC - discussion] __toArray()

[Steven Wade]

> I am open to the idea of having __toArray. I just have a few questions about 
> the RFC details.
> 
> 1. print_r($object) would somehow call __toArray you say. Why would it cause 
> a cast when nothing else is cast? I would prefer print_r((array) $person);

Originally I intended the proposal to be specific to user casting like you 
suggested but when writing the RFC I decided to pursue making the magic method 
and casting more in line with the behavior of __toString(). For example, when 
an object implements the __toString() method and you simply “echo $obj” PHP 
automatically casts the object for you.

> 2. In the parameter and return type examples you should add 
> declare(strict_types=0); so it's clear this only works in weak mode.

I think this is a good idea. I hadn’t looked into strict_types and how it 
handles strings and their casting. Thanks!

> 3. The weak point of this proposal is the by reference handling for sort et 
> al. Counterpoint: if you pass a variable to preg_match, then matches gets 
> converted from anything to array, so i believe by reference casting should 
> change the original value (https://3v4l.org/XUJ5m ). 
> This is weird, but consistent.

The proposal states that “array functions that operate on an array by reference 
such as sort or shuffle will not work on an object implementing __toArray() 
under this proposal”, and IMO that is consistent with other magical casting 
behaviors and I wouldn’t expect a class implementing __toArray() to be able to 
be written or referenced like a traditional array.

Re: [PHP-DEV] [RFC - discussion] __toArray()

[Benjamin Eberlei]

On Tue, Feb 4, 2020 at 2:10 PM Marco Pivetta  wrote:

> Linking (again) previous discussions:
> https://externals.io/message/98539#98539
>
> `__toArray` as a magic function call when `(array)` cast happen is a bad
> idea: it is a BC break, and it removes one of the very few interactions
> (with objects) that didn't cause any side-effects (
> https://externals.io/message/98539#98545,
> https://externals.io/message/98539#98567)
>

I think we can't classify it as BC break, because no existing code
implements __toArray at the moment, and hence it will not fail when this
feature is introduced and code gets upgraded to newer versions.

Its correct that this removes the last simple way to get access to all
properties on an object, although we can potentially remedy this with a
function (which makes a lot of sense).

>
> Greets,
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>
> On Tue, Feb 4, 2020 at 2:03 PM Steven Wade  wrote:
>
> > Hi all,
> >
> > I’d like to officially open my __toArray() RFC <
> > https://wiki.php.net/rfc/to-array> up to discussion. I’ve delayed
> > changing the status until I had more time to respond to the discussion,
> but
> > since it’s been brought up again ,
> I
> > figured now is the best time.
> >
> > https://wiki.php.net/rfc/to-array 
> >
> > Cheers,
> >
> > Steven Wade
>

Re: [PHP-DEV] [RFC - discussion] __toArray()

[Benjamin Eberlei]

On Tue, Feb 4, 2020 at 2:03 PM Steven Wade  wrote:

> Hi all,
>
> I’d like to officially open my __toArray() RFC <
> https://wiki.php.net/rfc/to-array> up to discussion. I’ve delayed
> changing the status until I had more time to respond to the discussion, but
> since it’s been brought up again , I
> figured now is the best time.
>
> https://wiki.php.net/rfc/to-array 
>

I am open to the idea of having __toArray. I just have a few questions
about the RFC details.

1. print_r($object) would somehow call __toArray you say. Why would it
cause a cast when nothing else is cast? I would prefer print_r((array)
$person);

2. In the parameter and return type examples you should add
declare(strict_types=0); so it's clear this only works in weak mode.

3. The weak point of this proposal is the by reference handling for sort et
al. Counterpoint: if you pass a variable to preg_match, then matches gets
converted from anything to array, so i believe by reference casting should
change the original value (https://3v4l.org/XUJ5m). This is weird, but
consistent.

Cheers,
>
> Steven Wade

Re: [PHP-DEV] [RFC - discussion] __toArray()

[Steven Wade]

> `__toArray` as a magic function call when `(array)` cast happen is a bad 
> idea: it is a BC break,

Adding a new magic method is not a backwards compatibility break. The PHP 
documentation on magic methods states:

"Caution PHP reserves all function names starting with __ as magical. It is 
recommended that you do not use function names with __ in PHP unless you want 
some documented magic functionality.”

Any user implementing their own methods prefixed with a double underscore is 
taking the chance that their code could break in the future.


> and it removes one of the very few interactions (with objects) that didn't 
> cause any side-effects (https://externals.io/message/98539#98545 
> , 
> https://externals.io/message/98539#98567 
> ) 

PHP 7.4 introduced the "get_mangled_object_vars()” as a result of these 
concerns.

Re: [PHP-DEV] What about a magic __toArray() method?

[Steven Wade]

> Oh there is even a rfc. https://wiki.php.net/rfc/to-array What is the
> status of this?

This RFC has now been moved to “under discussion” with the discussion happening 
here: https://externals.io/message/108369 

Re: [PHP-DEV] What about a magic __toArray() method?

[Marco Pivetta]

Hey Tom,

On Tue, Feb 4, 2020 at 1:55 PM Tom Gerrits  wrote:

> "(string) $var" doesn't seem a lot less explicit to me than
> "$var->toString()", but if it is coerced automatically when being
> passed to e.g. a function taking a string, that is of course a
> different story.
>

`(string) $var` is less explicit because `(string)` is an operation that
applies to a wide set of types, whereas any `->` applies only to `object`
types, and also has a specific name (the method name) on its right.
Restricting that operation to fewer supported types is not feasible at this
point, since `(string) null` is very much relied upon.

Coercions and implicit casting using the overloaded operators could
> perhaps also be limited to non-strict mode, if desired, which is also
> the case for scalar types currently, IIRC.
>

Is there any newly written code that doesn't use non-strict mode at all?
Programming without `declare(strict_types=1)` seems anachronistic at this
point.

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] [RFC - discussion] __toArray()

[Marco Pivetta]

Linking (again) previous discussions:
https://externals.io/message/98539#98539

`__toArray` as a magic function call when `(array)` cast happen is a bad
idea: it is a BC break, and it removes one of the very few interactions
(with objects) that didn't cause any side-effects (
https://externals.io/message/98539#98545,
https://externals.io/message/98539#98567)

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/


On Tue, Feb 4, 2020 at 2:03 PM Steven Wade  wrote:

> Hi all,
>
> I’d like to officially open my __toArray() RFC <
> https://wiki.php.net/rfc/to-array> up to discussion. I’ve delayed
> changing the status until I had more time to respond to the discussion, but
> since it’s been brought up again , I
> figured now is the best time.
>
> https://wiki.php.net/rfc/to-array 
>
> Cheers,
>
> Steven Wade

[PHP-DEV] Re: Moving the documentation to git

[Nikita Popov]

On Tue, Feb 4, 2020 at 1:48 PM Andreas Heigl  wrote:

> Hey Nikita, hey all.
>
> Am 04.02.20 um 12:11 schrieb Nikita Popov:
> > On Tue, Feb 4, 2020 at 8:09 AM Andreas Heigl  > > wrote:
>
> >
> > Hi Andreas,
> >
> > would you mind pushing the current en/de repos to
> > https://github.com/phpdoctest/en and de so it's possible to see how they
> > look like now?
>
> Find the repos (as they should be on git.php.net would I have access) at
> https://github.com/phpdoctest/de and https://github.com/phpdoctest/en
>
> They are updated after each run of the converter-tool which currently
> runs every two hours.
>

Thanks! It looks like currently the author mapping from svn -> git is
missing, which also means we don't get the mapping to github accounts. I'll
send you the author mapping file I have (which  is unfortunately somewhat
dated, maybe Peter has a newer one?), it would be great to preserve
authorship in a meaningful way.

Nikita

[PHP-DEV] [RFC - discussion] __toArray()

[Steven Wade]

Hi all,

I’d like to officially open my __toArray() RFC 
 up to discussion. I’ve delayed changing the 
status until I had more time to respond to the discussion, but since it’s been 
brought up again , I figured now is the 
best time.

https://wiki.php.net/rfc/to-array 

Cheers,

Steven Wade

Re: [PHP-DEV] What about a magic __toArray() method?

[Tom Gerrits]

  Correct: an explicit `$foo->toArray()` call suffices.

  For other readers, more about `$foo->toArray()` vs `(array) $foo` is
  described at

https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229


This is a valid point. Perhaps another problem lies at its base: why
can one cast null to a string in PHP? Would it be more appropriate to
throw a CastError or similar? Or does casting null to another type
make sense in some scenarios?

One could go as far as to only allow types that overload the
appropriate cast operator to cast to the type without error. This
implies the question of how to handle built-in types, such as casting
floats to string.


 - It is less explicit than choosing a purpose-specific method name


I think it's also important to mention whether this discussion is
about explicit casts only, or not - and also about implicit casts, or
coercion.

"(string) $var" doesn't seem a lot less explicit to me than
"$var->toString()", but if it is coerced automatically when being
passed to e.g. a function taking a string, that is of course a
different story.

Coercions and implicit casting using the overloaded operators could
perhaps also be limited to non-strict mode, if desired, which is also
the case for scalar types currently, IIRC.

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

[PHP-DEV] Re: Moving the documentation to git

[Andreas Heigl]

Hey Nikita, hey all.

Am 04.02.20 um 12:11 schrieb Nikita Popov:
> On Tue, Feb 4, 2020 at 8:09 AM Andreas Heigl  > wrote:

> 
> Hi Andreas,
> 
> would you mind pushing the current en/de repos to
> https://github.com/phpdoctest/en and de so it's possible to see how they
> look like now?

Find the repos (as they should be on git.php.net would I have access) at
https://github.com/phpdoctest/de and https://github.com/phpdoctest/en

They are updated after each run of the converter-tool which currently
runs every two hours.


Cheers

Andreas
-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] Re: [RFC] "arrayable" pseudo type hint

[Aimeos | Norbert Sendetzky]

I would like to modify my initial concept of an "arrayable" type because
PHP core developers seems to be in favor of the upcoming union data
types instead of adding a new "arrayable" pseudo type similar to "iterable".

So, I would like to propose an "Arrayable" interface that combines
ArrayAccess, Countable and Traversable interfaces and adds a toArray()
method:

interface Arrayable extends ArrayAccess, Countable, Traversable
{
public function toArray() : array;
}

Then, methods signatures can support array and Array-like objects:

function useArrayable( array|Arrayable $arg ) : array|Arrayable {
$cnt = count( $arg );
$value = $arg['key'];
foreach( $arg as $key => $entry );
is_object( $arg ) { $nativeArray = $arg->toArray(); }
return $arg;
}

Adding a toArray() method also avoids controversy around using a magic
__toArray() method, even if this would be easier for developers in this
case.

If union data types are available and "iterable" is implemented as
alias, an alias "arrayable" for "array|Arrayable" may be added as well.


Am 19.11.19 um 23:21 schrieb Aimeos | Norbert Sendetzky:
> Since PHP 7.1, there's the "iterable" pseudo type hint that matches
> "array" or "Traversable".
> 
> PHP frameworks would profit from support of an "arrayable" pseudo type
> hint that matches "array" and all objects that can be used like arrays.
> 
> For that, "arrayable" objects have to implement these interfaces:
> - ArrayAccess
> - Countable
> - Traversable (i.e. either Iterator or IteratorAggregate)
> 
> 
> Implementing "arrayable" pseudo type, we could pass arrays or all
> objects that can be used like arrays to methods and do:
> 
> function useArrayable( arrayable $arg ) : arrayable {
> $cnt = count( $arg );
> $value = $arg['key'];
> foreach( $arg as $key => $entry );
> return $arg;
> }
> 
> 
> Best use cases are:
> 
> - Laravel Collection
> (https://github.com/laravel/framework/blob/6.x/src/Illuminate/Support/Collection.php)
> 
> - Aimeos Map (https://github.com/aimeos/map)
> 
> 
> No new interface is proposed because we can check if objects implement:
> 
> ArrayAccess && Countable && Traversable
> 
> 
> Because "array" !== "arrayable", "arrayable objects will not be accepted
> by array_* functions and all functions that only use "array" as type
> hint for parameters and return types.
> 
> 
> This proposal is not obsolete by the implementation of union types (i.e.
> array|Traversable) because union data types are types/interfaces
> combined by OR. "arrayable" is a combination of OR and AND:
> 
> array|ArrayAccess
> 
> 
> Also, "arrayable" won't supersede "iterable" because
> 
> - "iterable" matches arrays, iterators and generators
> 
> - "arrayable" matches arrays and objects that can be used like arrays
> 
> 
> "Can be used like arrays" doesn't include support for empty() because it
> works for empty arrays but not for "arrayable" objects without elements.
> If possible and requested, this may be addressed by another RFC.
> 
> 
> As Larry Garfield suggested, this pre-RFC proposes concentrates on the
> "arrayable" pseudo type only.
> 
> It does NOT discusses that:
> 
> - arrayable objects can be converted to arrays (Steven Wade works on an
> RFC for a __toArray() magic function)
> 
> - ArrayObject or any other arrayable object makes the array_* functions
> less relevant in the future
> 
> - arrayable objects can be passed to array_* functions in the future
> 

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

Re: [PHP-DEV] What about a magic __toArray() method?

[Steven Wade]

> Oh there is even a rfc. https://wiki.php.net/rfc/to-array What is the
> status of this?

Hi there, I’m the author of that RFC. I intend to post it officially for 
discussion soon, I’ve just been busy and haven’t had the time that would be 
needed to respond to the discussion emails when they came in.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] What about a magic __toArray() method?

[Rowan Tommins]

On Tue, 4 Feb 2020 at 12:25, Tom Gerrits  wrote:

> "(string) $var" doesn't seem a lot less explicit to me than
> "$var->toString()"
>


No, but it's significantly less explicit than "$var->getDebugString()" or
"$var->formatHTML()" or "$var->getRawText()", all of which might exist on
one class, and any of which might be chosen as the implementation for
__toString()

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] What about a magic __toArray() method?

[Rowan Tommins]

On Tue, 4 Feb 2020 at 10:37, Marco Pivetta  wrote:

> Correct: an explicit `$foo->toArray()` call suffices.
>
> For other readers, more about `$foo->toArray()` vs `(array) $foo` is
> described at
>
> https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229
>


The pros and cons of overloading casts are roughly the same as those of
operator overloading in general:

on one hand:
+ It is more succinct than calling a method
+ It aids creation of richer Domain Specific Languages
on the other:
- It is less explicit than choosing a purpose-specific method name
- It is less flexible than having multiple related methods, or a method
with parameters
- It is harder to predict behaviour at a glance


> Or we can deprecate __toString() method at all and detect cast events
> instead. Would it make more sense? Something like this __casted().

If there was a good case made for how it should work, I'd be more
supportive of a general feature to overload casting, rather than making
(array) a special case.

One of many challenges would be working out when the cast should happen
implicitly. Should "iterable $foo" trigger an array cast if the object
isn't iterable? Should foreach()? Should strict_types change that behaviour
as it does for __toString(), even though it currently only applies to
scalar types?

Regards,
-- 
Rowan Tommins
[IMSoP]

[PHP-DEV] Re: Moving the documentation to git

[Nikita Popov]

On Tue, Feb 4, 2020 at 8:09 AM Andreas Heigl  wrote:

> Hey folks.
>
> During the last year I took a bit of time aside to bring the
> documentation from SVN to git. And about a month ago I informed the
> DOCs-Mailinglist about the current status and the fact that we are ready
> to move to the next step[1]. Now some tasks need to be done by people
> with appropriate karma to be able to get on with the whole thing, but
> all the background tasks are done and awaiting further processing.
>
> Sadly there was no response so far. Neither on the email as such nor on
> the different tasks.
>
> So the main question is now, how the PHP-Project wants to go on with
> moving the documentation from SVN to git? Is there any interest in
> continuing this project? And if so, who can either take on the necessary
> steps or provide us with the appropriate credentials and access rights
> that we can do them ourselves?
>
> Thanks for reading and looking forward to the results.
>
> Cheers
>
> Andreas
>
> [https://news-web.php.net/php.doc/969387429]
>

Hi Andreas,

would you mind pushing the current en/de repos to
https://github.com/phpdoctest/en and de so it's possible to see how they
look like now?

Nikita

Re: [PHP-DEV] What about a magic __toArray() method?

[Marco Pivetta]

Hey Midori,



On Tue, Feb 4, 2020 at 11:35 AM Midori Koçak  wrote:

> Marco, I've read it and your argument is strong. I think my opinion
> slightly moves towards Andreas, away from magic.
>
> here is something I wrote some days ago:
> https://github.com/midorikocak/arraytools/blob/master/src/ArrayConvertableTrait.php
>
> I guess you were saying something like this would be enough.
>
> Midori
>
>
Correct: an explicit `$foo->toArray()` call suffices.

For other readers, more about `$foo->toArray()` vs `(array) $foo` is
described at
https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] What about a magic __toArray() method?

[Midori Koçak]

Marco, I've read it and your argument is strong. I think my opinion
slightly moves towards Andreas, away from magic.

here is something I wrote some days ago:
https://github.com/midorikocak/arraytools/blob/master/src/ArrayConvertableTrait.php

I guess you were saying something like this would be enough.

Midori

On Tue, 4 Feb 2020 at 11:31, Marco Pivetta  wrote:

> Hey Midori,
>
> This has been discussed in more depth 2 years ago:
> https://externals.io/message/98539#98539
>
> In practice, the `(array)` cast is one of the few operations that don't
> cause observable side-effects in this programming language: let's please
> keep it as such.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>
> On Tue, Feb 4, 2020 at 8:15 AM Midori Koçak  wrote:
>
>> As you know we have __toString method that runs whenever an object is
>> typecasted to string or it is directly echoed.
>>
>> >
>> $class = (new class{
>>   public function __toString(){
>> echo "casted\n";
>> return "mahmut\n";
>>   }
>> });
>>
>> echo $class;
>> $casted = (string)$class;
>>
>> /*
>> prints:
>> casted
>> mahmut
>> casted
>> mahmut
>> */
>>
>>
>> As you know toArray() method implemented when an object is converted into
>> and array and most of the time when a plain data object is sent to
>> front-end.
>>
>> Having a magic method like __toString called __toArray would be useful to
>> detect and act on conversion events.
>>
>> Roughly it would be like:
>>
>> >
>> $class = (new class{
>>   public function __toArray(){
>> echo "casted\n";
>> return
>> [
>>   'key'=>'value'
>> ];
>>   }
>> });
>>
>>
>> $casted = (array)$class;
>> print_r($casted);
>>
>> /*
>> prints:
>> Array
>> (
>> [key] => value
>> )
>> mahmut
>> */
>>
>> What would you think? I think it would add value.
>>
>

Re: [PHP-DEV] Moving the documentation to git

[Derick Rethans]

On Tue, 4 Feb 2020, Andreas Heigl wrote:

> Sadly there was no response so far. Neither on the email as such nor on
> the different tasks.

Keep repeating them and poking the people. I have most definitely 
forgotten about what needs doing.

cheers,
Derick

-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Become my Patron: https://www.patreon.com/derickr
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] What about a magic __toArray() method?

[Marco Pivetta]

Hey Midori,

This has been discussed in more depth 2 years ago:
https://externals.io/message/98539#98539

In practice, the `(array)` cast is one of the few operations that don't
cause observable side-effects in this programming language: let's please
keep it as such.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/


On Tue, Feb 4, 2020 at 8:15 AM Midori Koçak  wrote:

> As you know we have __toString method that runs whenever an object is
> typecasted to string or it is directly echoed.
>
> 
> $class = (new class{
>   public function __toString(){
> echo "casted\n";
> return "mahmut\n";
>   }
> });
>
> echo $class;
> $casted = (string)$class;
>
> /*
> prints:
> casted
> mahmut
> casted
> mahmut
> */
>
>
> As you know toArray() method implemented when an object is converted into
> and array and most of the time when a plain data object is sent to
> front-end.
>
> Having a magic method like __toString called __toArray would be useful to
> detect and act on conversion events.
>
> Roughly it would be like:
>
> 
> $class = (new class{
>   public function __toArray(){
> echo "casted\n";
> return
> [
>   'key'=>'value'
> ];
>   }
> });
>
>
> $casted = (array)$class;
> print_r($casted);
>
> /*
> prints:
> Array
> (
> [key] => value
> )
> mahmut
> */
>
> What would you think? I think it would add value.
>

Re: [PHP-DEV] @official_php credentials?

[Derick Rethans]

Hi,

Adam gave them to me last night, so: me.

cheers,
Derick


On Tue, 4 Feb 2020, Nikita Popov wrote:

> Hi,
> 
> Does anyone know the credentials for the @official_php Twitter account?
> None of the releases since November last year (including 7.4.0) have been
> announced.
> 
> Regards,
> Nikita
> 

-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Become my Patron: https://www.patreon.com/derickr
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

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

[PHP-DEV] @official_php credentials?

[Nikita Popov]

Hi,

Does anyone know the credentials for the @official_php Twitter account?
None of the releases since November last year (including 7.4.0) have been
announced.

Regards,
Nikita