Re: [PHP-DEV] [RFC][Discussion] iterable_to_array() and iterable_count()
Hi Johannes, 2018-06-20 18:40 GMT+02:00 Johannes Schlüter : > > Is there any reason not to extend the existing functions to also allow > arrays? > Yes, this was discussed in the PR on GitHub: https://github.com/php/php-src/pull/3293#issuecomment-397082988 There are two main reasons to not do that: 1) Naming: iterator_*(), as the name suggests, is supposed to work with iterators. Making it work with arrays would be highly confusing. 2) Not altering/reusing existing functions: Changing behavior of existing functions that exist for many years is also confusing for consumers. In both cases this would make code harder to understand (i.e. taking version of PHP into efffect). > Also for the count one: Mind that iterator_count()/iterable_count() > doesn't respect the Countable interface and consumes the iterator, > which might not be resetable. A slightly better choice might be > > (is_array($iterable) || implements_countable($iterable)) ? > count($iterable) : iterator_count($iterable) > > And even then I would put a warning sign against blindly using it on > any iterator. > Just like with existing iterator_count(), this is up to the consumer to decide whether it's safe or not to use (especially with generators). It has exactly the same benefits and drawbacks. Also I'm not sure whether this is a downside of *_count() or not, IMHO it's designed specifically to count an iterator that is not Countable. So for an iterable, one may prefer: is_countable($value) ? count($value) : iterable_count($value) But again, this is up to the consumer to decide whether it's safe or not. johannes > Thanks, Michael
Re: [PHP-DEV] [RFC] Mixed type
On Sun, Jul 1, 2018 at 11:27 AM Rasmus Schultz wrote:
> I think we'll need the mixed type-hint in any case if we're to move
> ahead with generics?
I think Rasmus is alluding to this:
interface Iterator {
// rest of impl
}
So that we can make things generic but backwards compatible. Is that
what you are referring to, Rasmus?
-
The name "mixed" has been in our manual for over a decade (possibly
closer to 2 decades) so I am fine with adding it to the language even
if I would prefer a different name for the semantic. I think the most
common name in other languages for this type is "any", which sometimes
excludes null, so "?any" is the same as "mixed". I prefer "?any" but
would still vote in "mixed".
If we are going to add it I would prefer that we:
- Add a deprecation notice in 7.3 informing users that they need to
change their name.
- Create "mixed" or "?any" in 8.0.
This is the responsible thing to do if we are going to add it. There
is no functionality in 7.3 that will require it so there's no rush.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] User-defined object comparison
On 1 July 2018 19:45:03 BST, Rudolf Theunissen wrote: >> >> I think what I was suggesting is that if people in future want to >overload >> the operators specifically, we would want to provide an overload for ><=> >> that was separate from __compareTo, so that you could overload that >without >> breaking things like sorting. > > >I think it would be confusing to have both, or to have <=> not be >aligned >with __compareTo, because they are semantically equivalent. By >overloading ><=>, you have to also override comparison. Separating those is a recipe >for >confusion. That's the point though: with operator overloading as defined in many languages, they're only semantically equivalent if the person overloading the operator wants them to be. The most well-known example is probably the C++ operator >> which for primitives is a bit shift, but is overloaded for input and output to streams. If, on the other hand, operator overloading was added but constrained by the language to certain return values, there would be very little to be gained by overloading each comparison separately - all the extra overloads would have to return boolean anyway. >When you use the `<=>` operator, the return value is normalised to >either >-1, 0 or 1 which is consistent with the current behaviour. So the >object >you're returning in `compareTo` will be converted to an integer(1) That makes perfect sense to me, thanks. Just to reiterate, it's *not* what fans of free-form operator overloading would want, but I think it's the right behaviour for this feature. >One thing that your example brings up is that `<=>` is not exactly >equivalent to calling `__compareTo` directly, which would just return >the >raw value. Yeah, that's a good point. Directly calling magic methods is always a bit peculiar, but I think a note in the manual is probably enough. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] User-defined object comparison
>
> I think what I was suggesting is that if people in future want to overload
> the operators specifically, we would want to provide an overload for <=>
> that was separate from __compareTo, so that you could overload that without
> breaking things like sorting.
I think it would be confusing to have both, or to have <=> not be aligned
with __compareTo, because they are semantically equivalent. By overloading
<=>, you have to also override comparison. Separating those is a recipe for
confusion.
Apologies if this is covered in the RFC, but does that apply wherever they
> are used? For instance, what will the following code do?
> class SpaceStation {
> public $shape;
> public function __construct($shape='[]') {
> $this->shape = $shape;
> }
> public function __compareTo($other) {
> return new self($this->shape . '>=<' . $other->shape);
> }
> }
> $a = new SpaceStation;
> $b = new SpaceStation;
> $c = $a <=> $b; // Error? 0?
> echo $c->shape; // or will this echo '[]>=<[]'?
> $d = $a < $b; // Same result?
> $list = [$a, $b, $c, $d];
> sort($list); // Or will the error only be raised here?
When you use the `<=>` operator, the return value is normalised to either
-1, 0 or 1 which is consistent with the current behaviour. So the object
you're returning in `compareTo` will be converted to an integer(1) which
will make `$c` be `1`. Attempting to call `echo $c->shape` then makes no
sense.
`$a < $b` will be false because according to your return of `1`, `$a` would
be greater.
Sorting would then consider the LHS to always be greater also.
One thing that your example brings up is that `<=>` is not exactly
equivalent to calling `__compareTo` directly, which would just return the
raw value. This is exciting because it's a new issue that I'll add to the
RFC for consideration. Ideally we would like the operator and the magic
method to behave exactly the same, but that doesn't seem like a viable
option because we wouldn't want to magically translate the return value of
a function you're calling directly. The only option then is to simply
advise that <=> will normalise the return value of `__compareTo`. I'm
personally okay with that behaviour if it means the convention of the
return value of <=> remains intact.
Re: [PHP-DEV] [RFC] Mixed type
Nikita, I think we'll need the mixed type-hint in any case if we're to move ahead with generics? On Sat, Jun 30, 2018 at 10:30 PM, Nikita Popov wrote: > On Sat, Jun 30, 2018 at 10:17 PM, Sara Golemon wrote: > >> On Sat, Jun 30, 2018 at 3:08 PM, Stanislav Malyshev >> wrote: >> >> Together with Michael Moravec, we’d like to announce that we are >> pretending >> >> to open the Mixed Type RFC (https://wiki.php.net/rfc/mixed-typehint) >> next >> >> Monday (02/07) and we’d like to ask you to take a look into the PR on >> >> GitHub (https://github.com/php/php-src/pull/2603) and let us know if >> >> there's something else to do before it. >> > >> > I think this is wrong. This "type" - which is not really a type, of >> > course - does not add anything to the code, by definition - if you take >> > it out, everything would be the same. Things like that belong in the >> > documentation. Moreover, it makes the code harder to read, as the reader >> > should make mental effort to discard this non-type every time it is >> > mentioned, as it does not carry any information. >> > >> I would say that, in a world without union or intersection types, it >> adds to the readability of the code by explicitly saying, "We accept >> more than one type here, and we know we accept more than one type >> here." This is distinct from, "We have no idea what type we accept >> here." That adds to readability, it doesn't detract. >> >> I preface that with a mention of union/intersection types because that >> seems to be the *actual* problem this RFC is attempting to cope with >> while lacking the tools to do it right. I'm not super excited about >> this RFC because, as you say, this information could be easily encoded >> into the docblock for the function/method. Zero impact to the syntax, >> same benefit for the programmer and their readability. (More benefit, >> really, as docblock standards *do* permit union/intersection types. >> > > I'm basically with Sara here. Generally the feature has some merit, but I'm > sure that given our current type-system, and in particular the lack of > union types, this feature will be misused to annotate parameters that do > *not* accept completely arbitrary values, but where "mixed" is the best > approximation we have. For that reason I would prefer to defer this > addition until proper union types are supported. In that case mixed would > be a shortcut for the otherwise somewhat unwieldy type of > ?(bool|int|float|string|array|object|resource) (modulo the non-existence of > resource...) > > Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Mixed type
> > >> Together with Michael Moravec, we’d like to announce that we are >> pretending >> >> to open the Mixed Type RFC (https://wiki.php.net/rfc/mixed-typehint) >> next >> >> Monday (02/07) and we’d like to ask you to take a look into the PR on >> >> GitHub (https://github.com/php/php-src/pull/2603) and let us know if >> >> there's something else to do before it. >> > >> > I think this is wrong. This "type" - which is not really a type, of >> > course - does not add anything to the code, by definition - if you take >> > it out, everything would be the same. Things like that belong in the >> > documentation. Moreover, it makes the code harder to read, as the reader >> > should make mental effort to discard this non-type every time it is >> > mentioned, as it does not carry any information. >> > >> I would say that, in a world without union or intersection types, it >> adds to the readability of the code by explicitly saying, "We accept >> more than one type here, and we know we accept more than one type >> here." This is distinct from, "We have no idea what type we accept >> here." That adds to readability, it doesn't detract. >> >> I preface that with a mention of union/intersection types because that >> seems to be the *actual* problem this RFC is attempting to cope with >> while lacking the tools to do it right. I'm not super excited about >> this RFC because, as you say, this information could be easily encoded >> into the docblock for the function/method. Zero impact to the syntax, >> same benefit for the programmer and their readability. (More benefit, >> really, as docblock standards *do* permit union/intersection types. >> > > I'm basically with Sara here. Generally the feature has some merit, but > I'm sure that given our current type-system, and in particular the lack of > union types, this feature will be misused to annotate parameters that do > *not* accept completely arbitrary values, but where "mixed" is the best > approximation we have. For that reason I would prefer to defer this > addition until proper union types are supported. In that case mixed would > be a shortcut for the otherwise somewhat unwieldy type of > ?(bool|int|float|string|array|object|resource) (modulo the non-existence of > resource...) > > Nikita > Hello Nikita, Sara, Stan I agree with you that mixed in our current type system would be missused by those that want to document more than one type. So, the best to do would be to wait for a `union type` system in PHP, and than merge this feature to really document that a function accepts anything? Thanks, -- Gabriel Caruso
