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.
> -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 w
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 inst
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 pl
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 behavi
> -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 +
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
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
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.
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
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
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 implemen
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 h
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
>
> 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
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
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 th
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
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
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://w
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, o
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.
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 for
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 co
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 s
>
> > 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
> >
26 matches
Mail list logo
