[PHP-DEV] Re: [RFC] Mixed Typehint

[Benoit Schildknecht]

Le Tue, 19 Dec 2017 04:34:24 +0100, Michael Moravec   
a écrit:



Hello internals,

I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3:
https://wiki.php.net/rfc/mixed-typehint

The purpose of this RFC is to introduce "mixed" typehint on language  
level

to be used
as a valid typehint. PHP currently forces users to not use any type in  
case

the
type is mixed/unclear. This makes code inconsistent and less explicit.  
With

mixed,
it should be easy to eliminate this inconsistency and achieve fully type
hinted code.
It's a simple alias for the current behavior of no type and is fully
interchangeable.
This is mostly cosmetic change, no BC break to user-land is involved.

This RFC comes with a rather simple PR:
https://github.com/php/php-src/pull/2603

Please let me know what you think or if you find anything unclear.

Thanks!
Michael Moravec



It would be a +1 for me. Typehinting "mixed" tells way more than no  
typehinting at all. Because legacy code.


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

RE: [PHP-DEV] C++ and FAST_ZPP macros

[Anatol Belski]

> -Original Message-
> From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
> Golemon
> Sent: Tuesday, December 19, 2017 10:05 PM
> To: Anatol Belski 
> Cc: PHP internals 
> Subject: Re: [PHP-DEV] C++ and FAST_ZPP macros
> 
> On Tue, Dec 19, 2017 at 3:29 PM, Anatol Belski  wrote:
> >> As the blog post notes, it's a simple matter to work around the bug
> >> in extension code (indeed, an extension can simply opt to not use
> >> FAST_ZPP).  On the other hand, the fix is pretty basic, and existing
> >> functionality of the default expected type effectively being
> >> Z_EXPECTED_LONG (because both have a value of zero) is just a bit
> >> weird.
> >>
> >> Thoughts?  If I don't hear anything in a week, I'll just apply to 7.1 and 
> >> merge
> up.
> >>
> > C++11 requires a validity scope for enums, thus this change is unavoidable.
> > IMO your second suggestion were safer in the spirit of BC -
> > Z_EXPECTED_LONG instead of IS_UNDEF by default, and a new in master.
> > Just because a workaround is possible and otherwise the issue is not 
> > critical.
> >
> Yeah, the more I think about it, the more I realize that's the more prudent
> approach given the non-critical nature of this.  Could you clarify as 7.0 RM 
> if you
> want this on your branch? AIUI we're in security-only for 7.0 now, yes?
> 
In case of 7.0, it's a border case now. 7.0.27RC1 is out, the final is not yet. 
Strictly speaking, this issue doesn't qualify as a last second fit. 
Nevertheless I'd say, replacing IS_UNDEF with Z_EXPECTED_LONG is totally fine 
in C89 as it's only aware of the actual value, the issue in latest C++ is fixed 
thereby. From Jordi's stats 2017 is to see, that 7.0 was 1/3 in January at 
least, perhaps less today, so in general it'd be still some goal projects would 
target. As a last second patch, I think the nonintrusive variant would be 
acceptable, as C++ standard moves forward an we'd see ever more usage even of 
C++14 much later this year. If no one sees an obvious issue, please merge into 
7.0 next days. I'll be testing subsequently as well with any possible exts. 
7.0.27 GA is the cut.

Thanks

Anatol

Re: [PHP-DEV] instanceof survives non-object variables, but crashes on non-object constants.

[Andreas Hennings]

We can still do this as a follow-up.
The current fix is easy and straighforward.
What you suggest might be a good idea, but I think deserves more discussion.

On 19 December 2017 at 23:09, Michael Morris  wrote:
> What would it hurt to allow instanceof to return types other than object?
>
> $x instanceof NULL
> $x instanceof string
>
> and so on.  This would be more powerful and useful than throwing an error
> where one wasn't being thrown before. It also would let one operator detect
> all the types, rather than the plethora of detect functions we currently
> have.
>
> On Tue, Dec 19, 2017 at 4:48 PM, Nikita Popov  wrote:
>
>> On Sat, Dec 9, 2017 at 7:28 AM, Andreas Hennings 
>> wrote:
>>
>> > The following (https://3v4l.org/A2Tp6) is ok, it simply returns false:
>> >
>> > $x = 1;
>> > $x instanceof \stdClass;
>> >
>> >
>> > The following (https://3v4l.org/IdSBu) gives a fatal error:
>> >
>> > 1 instanceof \stdclass;
>> >
>> > t think this behavior is inconsistent, and we should consider changing
>> it.
>> >
>> > There are two options, but only one is BC.
>> >
>> > - Let 1 instanceof \stdClass return false, instead of crashing. -> seems
>> BC
>> > - Let $x instanceof \stdClass crash, if $x is not an object. -> BC break.
>> >
>> > So it seems the first would the option we should take.
>> > This is also what hhvm does, according to https://3v4l.org/IdSBu.
>> >
>>
>> I've prepared a PR for this change: https://github.com/php/php-
>> src/pull/2978
>>
>> From the discussion I'm understanding that our consensus is to implement
>> this change, so if there are no further objection I'll merge this in a few
>> days.
>>
>> Nikita
>>

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

Re: [PHP-DEV] instanceof survives non-object variables, but crashes on non-object constants.

[Michael Morris]

What would it hurt to allow instanceof to return types other than object?

$x instanceof NULL
$x instanceof string

and so on.  This would be more powerful and useful than throwing an error
where one wasn't being thrown before. It also would let one operator detect
all the types, rather than the plethora of detect functions we currently
have.

On Tue, Dec 19, 2017 at 4:48 PM, Nikita Popov  wrote:

> On Sat, Dec 9, 2017 at 7:28 AM, Andreas Hennings 
> wrote:
>
> > The following (https://3v4l.org/A2Tp6) is ok, it simply returns false:
> >
> > $x = 1;
> > $x instanceof \stdClass;
> >
> >
> > The following (https://3v4l.org/IdSBu) gives a fatal error:
> >
> > 1 instanceof \stdclass;
> >
> > t think this behavior is inconsistent, and we should consider changing
> it.
> >
> > There are two options, but only one is BC.
> >
> > - Let 1 instanceof \stdClass return false, instead of crashing. -> seems
> BC
> > - Let $x instanceof \stdClass crash, if $x is not an object. -> BC break.
> >
> > So it seems the first would the option we should take.
> > This is also what hhvm does, according to https://3v4l.org/IdSBu.
> >
>
> I've prepared a PR for this change: https://github.com/php/php-
> src/pull/2978
>
> From the discussion I'm understanding that our consensus is to implement
> this change, so if there are no further objection I'll merge this in a few
> days.
>
> Nikita
>

Re: [PHP-DEV] instanceof survives non-object variables, but crashes on non-object constants.

[Nikita Popov]

On Sat, Dec 9, 2017 at 7:28 AM, Andreas Hennings 
wrote:

> The following (https://3v4l.org/A2Tp6) is ok, it simply returns false:
>
> $x = 1;
> $x instanceof \stdClass;
>
>
> The following (https://3v4l.org/IdSBu) gives a fatal error:
>
> 1 instanceof \stdclass;
>
> t think this behavior is inconsistent, and we should consider changing it.
>
> There are two options, but only one is BC.
>
> - Let 1 instanceof \stdClass return false, instead of crashing. -> seems BC
> - Let $x instanceof \stdClass crash, if $x is not an object. -> BC break.
>
> So it seems the first would the option we should take.
> This is also what hhvm does, according to https://3v4l.org/IdSBu.
>

I've prepared a PR for this change: https://github.com/php/php-src/pull/2978

>From the discussion I'm understanding that our consensus is to implement
this change, so if there are no further objection I'll merge this in a few
days.

Nikita

RE: [PHP-DEV] Outstanding php.net account requests

[Anatol Belski]

> -Original Message-
> From: Johannes Schlüter [mailto:johan...@schlueters.de]
> Sent: Tuesday, December 5, 2017 3:22 PM
> To: Christoph M. Becker ; Pedro Magalhães
> 
> Cc: PHP internals list 
> Subject: Re: [PHP-DEV] Outstanding php.net account requests
> 
> On Di, 2017-12-05 at 14:57 +0100, Christoph M. Becker wrote:
> > On 05.12.2017 at 14:34, Pedro Magalhães wrote:
> >
> > >
> > > On Tue, Dec 5, 2017 at 12:49 PM, Johannes Schlüter  > > ters.de>
> > > wrote:
> > >
> > > >
> > > > we currently have 118 outstanding php.net account requests going
> > > > back to October 2016. If you recently tried to onboard somebody
> > > > could you verify whether they are still unapproved? If somebody
> > > > creates a
> > > > mass-
> > > > edit interface this would also be great, as the CSRF protection
> > > > makes deleting obvious spam requests a bit more annoying than it
> > > > neeeded. :-D
> > > >
> > > > If you see legit requests drop me (or somebody else with powers) a
> > > > note (including what kind of svn/git karma is needed) and I can
> > > > set it up.
> > > >
> > > > https://master.php.net/manage/users.php?search===0;
> > > > begin=
> > > > 0=20=1 (I believe this is visible to all @php.net
> > > > account holders)
> > > To add to that, AFAIK new requests via http://php.net/git-php.php
> > > are not sending the e-mail they should to this mailing list (PHP
> > > Group).
> > > Hence the
> > > large number of outstanding requests without follow-up.
> > An additional issue is that many account requests are made for PECL
> > accounts as well, and not everybody who has karma to approve or reject
> > VCS account requests has karma to handle PECL account requests.
> > Furthermore, while some have karma to approve VCS accounts, they may
> > not have karma to grant karma – so approving the accounts without
> > granting actual karma does not really make sense.
> 
> One question we need to answer there is "what should pecl be"? Do we want to
> bring PECL extensions onto php infrastructure (shared bug tracker, git.php.net
> which gives control to php.net i.e. for finding
> successors) or should PECL be a repository with pointers to github and 
> therelike?
> In the first case we should work on unifying the accounts.
> In the later case we should look into sizing the PECL site down and try to 
> have an
> "pecl" installer which can fetch stuff directly from git, similar to 
> packagist.org,
> then we could simplify the process there ..
> 
IMO it is a strategical question and we should keep up with the real world. It 
was one of the reasons for Pickle to come to life, which however didn't come to 
the optimal end implementation meanwhile. There's github, bitbucket, etc. As a 
usage example - an extension could be accepted on PECL, but indeed be released 
on GitHub only. The PECL site could sync that release to PECL, the pecl tool 
could be aware there were some release outside at the places we'd define as 
safe. Similar thoughts would be if it came to the Composer integration - the 
more it'd ease access to the extensions, the more profit it would be in the 
end. Perhaps it's just me, but reading on an arbitrary PHP project page 
something like "no extensions required" sounds really amiss. 

Basically, I'd suggest we don't pretend there's no world outta PECL and make 
things easy for use case scenarios where fe people only work on GitHub. For 
instance, we could also accept authentication with GitHub and others on PECL, 
with all the logical consequences. There's already quite some work with the 
regard to PR handling on GitHub for qa.php.net. Of course, it wouldn't deny the 
classic PECL use case scenario.

Regards

Anatol

Re: [PHP-DEV] C++ and FAST_ZPP macros

[Sara Golemon]

On Tue, Dec 19, 2017 at 3:29 PM, Anatol Belski  wrote:
>> As the blog post notes, it's a simple matter to work around the bug in 
>> extension
>> code (indeed, an extension can simply opt to not use FAST_ZPP).  On the other
>> hand, the fix is pretty basic, and existing functionality of the default 
>> expected
>> type effectively being Z_EXPECTED_LONG (because both have a value of zero) is
>> just a bit
>> weird.
>>
>> Thoughts?  If I don't hear anything in a week, I'll just apply to 7.1 and 
>> merge up.
>>
> C++11 requires a validity scope for enums, thus this change is unavoidable.
> IMO your second suggestion were safer in the spirit of BC - Z_EXPECTED_LONG
> instead of IS_UNDEF by default, and a new in master. Just because a workaround
> is possible and otherwise the issue is not critical.
>
Yeah, the more I think about it, the more I realize that's the more
prudent approach given the non-critical nature of this.  Could you
clarify as 7.0 RM if you want this on your branch? AIUI we're in
security-only for 7.0 now, yes?

-Sara

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

Re: [PHP-DEV] [RFC] Mixed Typehint

[Fleshgrinder]

On 12/19/2017 9:59 PM, li...@rhsoft.net wrote:
> yes, it's mostly cosmetic (frankly even the OP statet this in the
> initial mail) but if that comes witout a noticebale price to pay why not?
> 
> "It's a simple alias for the current behavior of no type and is fully
> interchangeable" sounds like it could even be optimized out at compile
> time of the script - so "you don't need it" is not much compelling for me
> 

Adding that optimization step is already more effort than not
introducing it in the first place, don't you agree?

Seriously, I am neutral on the topic in itself. Fact is that it is an
unnecessary change from a technical perspective and it will not bring
PHP forward in adopting a sound type system. I just wanted to show
support for Stanislav's position because he is simply right from a
technical point of view (which imho is more important in language design).

There is no argument against the "we like it pretty".

-- 
Richard "Fleshgrinder" Fussenegger

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

Re: [PHP-DEV] [RFC] Mixed Typehint

[li...@rhsoft.net]

Am 19.12.2017 um 21:53 schrieb Fleshgrinder:

On 12/19/2017 8:01 PM, li...@rhsoft.net wrote:

but that's a different thing and both don't collide


It's not a different thing, that's what I try to tell you. They do not
collide, of course not, but having the others is going to make mixed
useless.

In other words: if there is no type left to constraint to, it must be
the top type. (Note that we already have the ability to constraint to
the bottom type void.)

Other languages invest quite some time into getting rid of annotating
their top types (and type inversion) and we already have this
functionality and you (not you in person but the collective here asking
for it) want to introduce it. Stanislav is right, this type would be
there for no technical reason.

It is only for cosmetics or maybe to allow people to say "my codebase is
fully type constrained". Which is literally a meaningless statement.


yes, it's mostly cosmetic (frankly even the OP statet this in the 
initial mail) but if that comes witout a noticebale price to pay why not?


"It's a simple alias for the current behavior of no type and is fully
interchangeable" sounds like it could even be optimized out at compile 
time of the script - so "you don't need it" is not much compelling for me


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

Re: [PHP-DEV] [RFC] Mixed Typehint

[Fleshgrinder]

On 12/19/2017 8:01 PM, li...@rhsoft.net wrote:
> but that's a different thing and both don't collide
> 

It's not a different thing, that's what I try to tell you. They do not
collide, of course not, but having the others is going to make mixed
useless.

In other words: if there is no type left to constraint to, it must be
the top type. (Note that we already have the ability to constraint to
the bottom type void.)

Other languages invest quite some time into getting rid of annotating
their top types (and type inversion) and we already have this
functionality and you (not you in person but the collective here asking
for it) want to introduce it. Stanislav is right, this type would be
there for no technical reason.

It is only for cosmetics or maybe to allow people to say "my codebase is
fully type constrained". Which is literally a meaningless statement.

-- 
Richard "Fleshgrinder" Fussenegger

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

RE: [PHP-DEV] C++ and FAST_ZPP macros

[Anatol Belski]

Hi Sara,

> -Original Message-
> From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
> Golemon
> Sent: Monday, December 18, 2017 8:44 PM
> To: PHP internals 
> Subject: [PHP-DEV] C++ and FAST_ZPP macros
> 
> This blog post came across my twitter today and it's certainly legit.
> https://cismon.net/2017/12/18/Fast-ZPP-s-Incompatibility-with-CPP/
> 
> I tossed together this quick and dirty fix (and tested it with a simple C++
> extension), but I wanted to get a read on what branch folks think it should be
> applied to.
> https://github.com/sgolemon/php-
> src/commit/469ddd26331dbd736ad13eaac7170ccc43d09c7f
> 
> As the blog post notes, it's a simple matter to work around the bug in 
> extension
> code (indeed, an extension can simply opt to not use FAST_ZPP).  On the other
> hand, the fix is pretty basic, and existing functionality of the default 
> expected
> type effectively being Z_EXPECTED_LONG (because both have a value of zero) is
> just a bit
> weird.
> 
> Thoughts?  If I don't hear anything in a week, I'll just apply to 7.1 and 
> merge up.
> 
C++11 requires a validity scope for enums, thus this change is unavoidable. IMO 
your second suggestion were safer in the spirit of BC - Z_EXPECTED_LONG instead 
of IS_UNDEF by default, and a new in master. Just because a workaround is 
possible and otherwise the issue is not critical.

Regards

Anatol 

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

[Rowan Collins]

On 13/12/2017 07:12, Michał Brzuchalski wrote:

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



My thoughts were actually going along the same lines: basically, the 
current implementation of namespaces is, I think by design, very 
conservative in what a namespace represents. A namespace doesn't have 
any identity, and doesn't have any codified structure, it's just a 
shorthand for referring to similarly named classes (plus functions and 
constants).


There are several things that I think would feel more natural with 
"packages" than namespaces as they exist today:


- Declare directives, as discussed here
- Visibility modifiers, e.g. a "private class", accessible only within 
its package
- Per-package autoloaders, that only get called for classes in that 
package, rather than a global autoloader which parses out the prefixes 
it's interested in
- An autoloader callback that fires once for each package, to setup 
these options


Another difference is that namespaces tend to form deep hierarchies, but 
you're unlikely to set options at every level of the hierarchy. For 
instance, you probably don't want to set strict_types on for 
Acme\MyPackage\Input but off for Acme\MyPackage\Output. So a separate 
syntax to mark which level is the "package" would reduce the number of 
places a setting could be set, which would reduce the number of places 
you'd need to look - a bit like having Apache settings in a VirtualHost 
for the whole site, rather than .htaccess files in every directory.


All that being said, I'm not 100% convinced this is solving a real 
problem. Yes, the option has to be set in every file, but that's because 
it effects the way that file is compiled, and the compiler sees one file 
at a time. The same applies to the "namespace" directive, which you 
might otherwise set against a particular directory. I don't see a 
pressing need to add the complexity.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC] Mixed Typehint

[li...@rhsoft.net]

Am 19.12.2017 um 19:19 schrieb Fleshgrinder:

On 12/19/2017 6:43 PM, Andreas Hennings wrote:

The argument, which I support, is that "mixed" would allow to
distinguish against cases of "developer forgot to add a type hint" or
"no type hint due to legacy / BC reasons".
Also, with a "mixed" type hint, you know it is not "void" (this is
still the same argument).


The developer forgot the type constraint if there is no type constraint in:

1. the code
2. the DocBlock

This is a simple rule that you can already adopt without any changes to
the language. The thing is that mixed is not required at all at the
moment PHP supports more sophisticated type constructs. As I said
earlier, pursue them, not this.

PS: It's interesting how people fail to see the power of union and
intersection. This is currently happening on the Kotlin side too.

A simple example for a union type was already given: `string|int`


i see the power and have hundrets of definitions where i would add such 
hints instead nothing if it would be supported


but that's a different thing and both don't collide

"It's a simple alias for the current behavior of no type and is fully 
interchangeable" from this RFC about mixed is completly unrelated to 
union types


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

Re: [PHP-DEV] [RFC] Mixed Typehint

[Fleshgrinder]

On 12/19/2017 6:43 PM, Andreas Hennings wrote:
> The argument, which I support, is that "mixed" would allow to
> distinguish against cases of "developer forgot to add a type hint" or
> "no type hint due to legacy / BC reasons".
> Also, with a "mixed" type hint, you know it is not "void" (this is
> still the same argument).
> 

The developer forgot the type constraint if there is no type constraint in:

1. the code
2. the DocBlock

This is a simple rule that you can already adopt without any changes to
the language. The thing is that mixed is not required at all at the
moment PHP supports more sophisticated type constructs. As I said
earlier, pursue them, not this.

PS: It's interesting how people fail to see the power of union and
intersection. This is currently happening on the Kotlin side too.

A simple example for a union type was already given: `string|int`.
Although in this case I would argue that anything that is convertible to
a hash (e.g. `Hashable` as found in php-ds) and ensures an equivalence
relation (not partial like float) should be usable as a key in an
associative array. The introduction of dedicated types for this is
definitely required in the language. That being said, union types are
usually of interest if you are interacting with some library code that
you cannot change (e.g. add interfaces to an existing type). Of course,
one could argue that the introduction of dedicated interfaces in your
own codebase plus adapters is the way to go but this requires much more
effort than the in-place union declaration.

Discriminating unions would be much nicer but that is something a proper
enum impl should cover.

Intersection is a whole other beast that is actually more powerful than
the simple unions we know from PhpDoc. Consider the following example:

interface Writer
interface Reader
interface Seekable
interface AutoCloseable
interface Closeable

We could now continue and provide ReadableWriter, SeekableWriter,
SeekableReadableWriter, ... but this already gets out of hand. An
intersection on the other hand allows you to define exactly the features
you require:

fn f(Closeable & Seekable & Writer writer)

This can of course be provided with a generics impl which would probably
make the parsing impl simpler:

fn f(T writer)

-- 
Richard "Fleshgrinder" Fussenegger

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

Re: [PHP-DEV] [RFC] Mixed Typehint

[Andreas Hennings]

> For correctness: `callable` is not the union `string | array | object` 
> because only certain kinds of strings, arrays, and objects are accepted.

Correct.

> this thread is about `mixed`
> which I would vote against. As our type-system stands it provides
> almost no value

The argument, which I support, is that "mixed" would allow to
distinguish against cases of "developer forgot to add a type hint" or
"no type hint due to legacy / BC reasons".
Also, with a "mixed" type hint, you know it is not "void" (this is
still the same argument).


On 19 December 2017 at 18:38, li...@rhsoft.net  wrote:
> IMHO the wrong question, the right ones would be
>
> a) how much work is it to implement
> b) does it any harm
> c) is it maintainable and does it bring relevant maintainance cost

I think we do need to explain whether a feature "provides value", so
Levi's question is not wrong.
Simply "does no harm" is not enough.
We just disagree on the answer, we actually do think it provides value.


On 19 December 2017 at 18:30, Levi Morrison  wrote:
> On Tue, Dec 19, 2017 at 10:05 AM, Andreas Hennings  
> wrote:
>> We already have other "meta" types.
>> E.g. "callable" can be a string, an array, an object with __invoke().
>> A "numeric" can be float or int.
>> A "iterable" can be an array or an traversable object.
>
> For correctness: `callable` is not the union `string | array | object`
> because only certain kinds of strings, arrays, and objects are
> accepted.
>
>> Personally I don't think we need every possible union, let alone 
>> intersections.
>
> How many do we need to have for us to make the conclusion we should
> stop making special-cases in the engine and generalize it?
>
> In any case we are straying off-topic: this thread is about `mixed`
> which I would vote against. As our type-system stands it provides
> almost no value. If our type system ever changes and it suddenly
> provides value then it should be proposed at that point.

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

Re: [PHP-DEV] [RFC] Mixed Typehint

[li...@rhsoft.net]

Am 19.12.2017 um 18:30 schrieb Levi Morrison:

In any case we are straying off-topic: this thread is about `mixed`
which I would vote against. As our type-system stands it provides
almost no value. If our type system ever changes and it suddenly
provides value then it should be proposed at that point


IMHO the wrong question, the right ones would be

a) how much work is it to implement
b) does it any harm
c) is it maintainable and does it bring relevant maintainance cost

the fact that in a sane project where you use typehints wherever it is 
possible that you then can distinct between forgotten typehint versus 
explicit statet brings a benefit for userland code while nobody is 
forced to use it


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

Re: [PHP-DEV] [RFC] Mixed Typehint

[Levi Morrison]

On Tue, Dec 19, 2017 at 10:05 AM, Andreas Hennings  wrote:
> We already have other "meta" types.
> E.g. "callable" can be a string, an array, an object with __invoke().
> A "numeric" can be float or int.
> A "iterable" can be an array or an traversable object.

For correctness: `callable` is not the union `string | array | object`
because only certain kinds of strings, arrays, and objects are
accepted.

> Personally I don't think we need every possible union, let alone 
> intersections.

How many do we need to have for us to make the conclusion we should
stop making special-cases in the engine and generalize it?

In any case we are straying off-topic: this thread is about `mixed`
which I would vote against. As our type-system stands it provides
almost no value. If our type system ever changes and it suddenly
provides value then it should be proposed at that point.

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

Re: [PHP-DEV] [RFC] Mixed Typehint

[Andreas Hennings]

We already have other "meta" types.
E.g. "callable" can be a string, an array, an object with __invoke().
A "numeric" can be float or int.
A "iterable" can be an array or an traversable object.

Technically you are right, my "anything that could be an array index"
would be equivalent to "string|int".

Personally I don't think we need every possible union, let alone intersections.
I am not strictly opposed to them, but don't find them as necessary.
Most well-written functions will have one return type.
But there are some cases of naturally occuring union or meta types,
which might deserve their own meta type name.



On 19 December 2017 at 16:28, Levi Morrison  wrote:
> On Tue, Dec 19, 2017 at 4:47 AM, Andreas Hennings  wrote:
>> On 19 December 2017 at 08:06, Fleshgrinder  wrote:
>>> What is really needed are `scalar`, `number`, union types, intersection
>>> types, and all that together with generics.
>>
>> Do we have ongoing discussions or RFCs for those already?
>> I know we have one for generics, which seems somehow stuck,
>> https://wiki.php.net/rfc/generics
>
> No. Work is quietly being done on parameterized types (aka generics) here:
>
> https://github.com/morrisonlevi/php-src/tree/parameterized_traits
>
> There really isn't a lot to discuss at this stage anyway; the
> technical implementation is paramount.
>
>> What would "scalar" mean exactly? string+int+float?
>
> Scalar and number are just ways of naming certain union types which
> feature was already declined. Maybe a single RFC which targets both
> union and intersection types would pass. Our `is_scalar` function
> returns true for integer, float, string or boolean; a scalar type
> should mirror that definition: int | float | string | bool.
>
>> I would sometimes like a string+int, for "everything that can be an array 
>> key".
>
> This is just another named union for `string | int`.

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

Re: [PHP-DEV] [RFC] Mixed Typehint

[Levi Morrison]

On Tue, Dec 19, 2017 at 4:47 AM, Andreas Hennings  wrote:
> On 19 December 2017 at 08:06, Fleshgrinder  wrote:
>> What is really needed are `scalar`, `number`, union types, intersection
>> types, and all that together with generics.
>
> Do we have ongoing discussions or RFCs for those already?
> I know we have one for generics, which seems somehow stuck,
> https://wiki.php.net/rfc/generics

No. Work is quietly being done on parameterized types (aka generics) here:

https://github.com/morrisonlevi/php-src/tree/parameterized_traits

There really isn't a lot to discuss at this stage anyway; the
technical implementation is paramount.

> What would "scalar" mean exactly? string+int+float?

Scalar and number are just ways of naming certain union types which
feature was already declined. Maybe a single RFC which targets both
union and intersection types would pass. Our `is_scalar` function
returns true for integer, float, string or boolean; a scalar type
should mirror that definition: int | float | string | bool.

> I would sometimes like a string+int, for "everything that can be an array 
> key".

This is just another named union for `string | int`.

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

Re: [PHP-DEV] [RFC] Mixed Typehint

[Andreas Hennings]

On 19 December 2017 at 08:06, Fleshgrinder  wrote:
> What is really needed are `scalar`, `number`, union types, intersection
> types, and all that together with generics.

Do we have ongoing discussions or RFCs for those already?
I know we have one for generics, which seems somehow stuck,
https://wiki.php.net/rfc/generics

What would "scalar" mean exactly? string+int+float?
I would sometimes like a string+int, for "everything that can be an array key".

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

Re: [PHP-DEV] [RFC] Mixed Typehint

[Andreas Hennings]

Perhaps this is the same reason why we add "public" keyword, even
though a member is implicitly public by default.

On 19 December 2017 at 12:34, Andreas Hennings  wrote:
> I agree with Michael Kliewe.
> When looking at code, I want to distinguish between:
> - Developer forgot to add a type hint, or it was left out for legacy /
> BC reasons.
> - The function can really return various types, at least too many for
> any more specific type hint.
>
>
> On 19 December 2017 at 04:57, li...@rhsoft.net  wrote:
>> no, mixed is used in phpdoc comments to say "no type specified at all" when 
>> a param accepts anything and in case of "@return mixed" that it can return 
>> void, array, int.
>
> I think "mixed" should not include "void".
> A well-written method/function either has a return value or not. It it
> is type-hinted as "mixed", then we should expect it to have a return
> value.
>
> On 19 December 2017 at 08:06, Fleshgrinder  wrote:
>> What is really needed are `scalar`, `number`, union types, intersection
>> types, and all that together with generics.
>
> I would like to see those too, but they are not mutually exclusive
> with "mixed" and should rather be discussed separately.
>
>
>
> On 19 December 2017 at 11:01, Michael Kliewe  wrote:
>> Am 19.12.2017 um 07:32 schrieb Stanislav Malyshev:
>>>
 I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3:
 https://wiki.php.net/rfc/mixed-typehint

 The purpose of this RFC is to introduce "mixed" typehint on language level
 to be used
 as a valid typehint. PHP currently forces users to not use any type in case
 the
 type is mixed/unclear. This makes code inconsistent and less explicit. With
>>> I'm not sure what's the point of it. "mixed" means "any type". Not
>>> writing a type means "any type". So why waste space and add something
>>> that contributes nothing when everybody is already using the current
>>> convention and the new one does not add anything at all?
>> A "mixed" type hint says that it's really "mixed", and the developer who
>> wrote that code did not forget to add a type hint.
>> If you see a place where a type hint is missing, you don't know if it's
>> mixed, or the developer/you missed to write the correct type hint.
>>
>> That's the benefit I see. I would explicitly write "mixed" everywhere in
>> a fully type-hinted codebase, to eliminate this thought while reading:
>> Is it really mixed, or was this place overseen and it's not mixed, but
>> something else...
>> Because it's optional, nobody is hurt, but some people (like me) could
>> add this explicit information.
>>
>> Michael
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>

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

Re: [PHP-DEV] [RFC] Mixed Typehint

[Andreas Hennings]

I agree with Michael Kliewe.
When looking at code, I want to distinguish between:
- Developer forgot to add a type hint, or it was left out for legacy /
BC reasons.
- The function can really return various types, at least too many for
any more specific type hint.


On 19 December 2017 at 04:57, li...@rhsoft.net  wrote:
> no, mixed is used in phpdoc comments to say "no type specified at all" when a 
> param accepts anything and in case of "@return mixed" that it can return 
> void, array, int.

I think "mixed" should not include "void".
A well-written method/function either has a return value or not. It it
is type-hinted as "mixed", then we should expect it to have a return
value.

On 19 December 2017 at 08:06, Fleshgrinder  wrote:
> What is really needed are `scalar`, `number`, union types, intersection
> types, and all that together with generics.

I would like to see those too, but they are not mutually exclusive
with "mixed" and should rather be discussed separately.



On 19 December 2017 at 11:01, Michael Kliewe  wrote:
> Am 19.12.2017 um 07:32 schrieb Stanislav Malyshev:
>>
>>> I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3:
>>> https://wiki.php.net/rfc/mixed-typehint
>>>
>>> The purpose of this RFC is to introduce "mixed" typehint on language level
>>> to be used
>>> as a valid typehint. PHP currently forces users to not use any type in case
>>> the
>>> type is mixed/unclear. This makes code inconsistent and less explicit. With
>> I'm not sure what's the point of it. "mixed" means "any type". Not
>> writing a type means "any type". So why waste space and add something
>> that contributes nothing when everybody is already using the current
>> convention and the new one does not add anything at all?
> A "mixed" type hint says that it's really "mixed", and the developer who
> wrote that code did not forget to add a type hint.
> If you see a place where a type hint is missing, you don't know if it's
> mixed, or the developer/you missed to write the correct type hint.
>
> That's the benefit I see. I would explicitly write "mixed" everywhere in
> a fully type-hinted codebase, to eliminate this thought while reading:
> Is it really mixed, or was this place overseen and it's not mixed, but
> something else...
> Because it's optional, nobody is hurt, but some people (like me) could
> add this explicit information.
>
> Michael
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] [RFC] Mixed Typehint

[Michael Kliewe]

Am 19.12.2017 um 07:32 schrieb Stanislav Malyshev:
>
>> I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3:
>> https://wiki.php.net/rfc/mixed-typehint
>>
>> The purpose of this RFC is to introduce "mixed" typehint on language level
>> to be used
>> as a valid typehint. PHP currently forces users to not use any type in case
>> the
>> type is mixed/unclear. This makes code inconsistent and less explicit. With
> I'm not sure what's the point of it. "mixed" means "any type". Not
> writing a type means "any type". So why waste space and add something
> that contributes nothing when everybody is already using the current
> convention and the new one does not add anything at all?
A "mixed" type hint says that it's really "mixed", and the developer who
wrote that code did not forget to add a type hint.
If you see a place where a type hint is missing, you don't know if it's
mixed, or the developer/you missed to write the correct type hint.

That's the benefit I see. I would explicitly write "mixed" everywhere in
a fully type-hinted codebase, to eliminate this thought while reading:
Is it really mixed, or was this place overseen and it's not mixed, but
something else...
Because it's optional, nobody is hurt, but some people (like me) could
add this explicit information.

Michael

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

Re: [PHP-DEV] [RFC] Mixed Typehint

[Christian Schneider]

Am 19.12.2017 um 09:49 schrieb Stanislav Malyshev :
>> The current one isn't any convention, it's just not possible to do
>> something else. There's nothing that explicitly allows saying "I accept
>> all types", rather than "The type I accept is unspecifed".
> 
> There could be of course logical constructions that are not supported by
> the type system. "mixed" however has the accepted meaning - and that
> meaning is exactly the same as not specifying the type. I do not see any
> additional use of type that only means "unspecified type" - it looks
> like its sole reason is so that somebody could say "I now have lots of
> types in my code!" which does not seem to me a worthy goal. Types should
> serve a purpose, this one serves none.

I agree, if you want to document that you code accepts mixed types you could 
simple write /* mixed */, i.e. a comment.
If you're talking about tool support then the tool could also support this 
comment. Would not be unheard of either.

- Chris


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

Re: [PHP-DEV] [RFC] Mixed Typehint

[Stanislav Malyshev]

Hi!

> Why document code? It contributes nothing to the behavior of the code,
> well, unless you parse it as annotations.

I am not sure I understand - are you arguing for supporting "mixed" in
*documentation*? Then it's already supported and there's no need for any
RFC. But if you're arguing for supporting it in the code, it's useless
and has nothing to do with documentation - which you'd have to write
anyway.

> The current one isn't any convention, it's just not possible to do
> something else. There's nothing that explicitly allows saying "I accept
> all types", rather than "The type I accept is unspecifed".

There could be of course logical constructions that are not supported by
the type system. "mixed" however has the accepted meaning - and that
meaning is exactly the same as not specifying the type. I do not see any
additional use of type that only means "unspecified type" - it looks
like its sole reason is so that somebody could say "I now have lots of
types in my code!" which does not seem to me a worthy goal. Types should
serve a purpose, this one serves none.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] Mixed Typehint

[Niklas Keller]

>
> > I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3:
> > https://wiki.php.net/rfc/mixed-typehint
> >
> > The purpose of this RFC is to introduce "mixed" typehint on language
> level
> > to be used
> > as a valid typehint. PHP currently forces users to not use any type in
> case
> > the
> > type is mixed/unclear. This makes code inconsistent and less explicit.
> With
>
> I'm not sure what's the point of it. "mixed" means "any type". Not
> writing a type means "any type". So why waste space and add something
> that contributes nothing when everybody is already using the current
> convention and the new one does not add anything at all?


Why document code? It contributes nothing to the behavior of the code,
well, unless you parse it as annotations.

The current one isn't any convention, it's just not possible to do
something else. There's nothing that explicitly allows saying "I accept all
types", rather than "The type I accept is unspecifed".

That said, I'm not sure myself. I guess a more complex type which can't be
expressed currently (like a union type) might also use "mixed" then.

Regards, Niklas


> > mixed,
> > it should be easy to eliminate this inconsistency
>
> There's no "inconsistency" here.
>
> > and achieve fully type hinted code.
>
> This is not an "achievement" - adding prefixes for the sake of all
> variables having prefixes that mean nothing is not an "achievement". I
> do not see any point in it.
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>