On Fri, Feb 20, 2015 at 10:48 PM, Robert Stoll p...@tutteli.ch wrote:
Hi Dmitry and Anthony,
I was skimming through your conversation about JIT/AOT and that type hints
would allow to optimise few things.
I do not know if you are aware of the following but type hints can be
passed by. Hence
2015-02-21 17:26 GMT-04:00 Pavel Kouřil pajou...@gmail.com:
Hello,
finally got to this, after a while of thinking - the first part was
answered before, so I'll get only to the str_replace now. :)
Basically, each of the 8 different version based on parameters does
different thing, if I'm
Francois,
On Fri, Feb 20, 2015 at 8:14 PM, François Laupretre franc...@php.net wrote:
Hi Anthony,
I guess you would keep supporting __toString() ? So, you should probably
consider 'string' as 'string|object'.
Adding this case to 'float' meaning 'int|float' and 'callable' resolving to
Zeev,
Anthony,
Following Adam's analysis of the timeline, taking the more 'strict' (no pun
intended!) interpretation of the timeline RFC, we still have until tomorrow
to start the discussion and still target it for 7.0, no? Given the
importance of this topic, I'd go for the more lax
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Saturday, February 21, 2015 5:23 PM
To: Zeev Suraski
Cc: Larry Garfield; internals@lists.php.net
Subject: Re: [PHP-DEV] Reviving scalar type hints
I'm fine with that. My interpretation was that the feature
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Saturday, February 21, 2015 1:36 AM
To: Larry Garfield
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Reviving scalar type hints
Larry,
On Fri, Feb 20, 2015 at 6:31 PM, Larry Garfield la
Francois,
Adding this case to 'float' meaning 'int|float' and 'callable' resolving to
'string|array|object', are you sure it's worth the pain implementing and
supporting a dual-mode mechanism, compared to the ruleset I am intending to
propose (currently in draft):
De : Anthony Ferrara [mailto:ircmax...@gmail.com]
Callable is an existing rule, which is not subject to the strict discussion.
I was talking of __invoke() and closures, wich extend callable from
'string|array' to 'string|array|object'. But, I agree, it just extends the rule.
None of the
On Mon, Feb 16, 2015 at 9:50 PM, François Laupretre franc...@php.net wrote:
De : Pavel Kouril [mailto:pajou...@gmail.com]
Hello,
I know this is probably a pretty unpopular opinion in PHP (based on
the replies I got in the other thread), but different values for
parameters should be IMHO
De : Anthony Ferrara [mailto:ircmax...@gmail.com]
I've taken a look at that proposal, and here are my comments:
Thanks
1. This RFC only talks about ZPP. I assume you're also talking about
exposing the same ruleset to userland?
Right. This is a sub-RFC of STH main. As it is stated in
hi Dmitry,
On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov dmi...@zend.com wrote:
On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara ircmax...@gmail.com
wrote:
Larry,
Anthony, can you expand here at all about the practical benefits of
strong-typing for variable passing for the compiler?
On Fri, Feb 20, 2015 at 5:08 PM, Pierre Joye pierre@gmail.com wrote:
hi Dmitry,
On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov dmi...@zend.com wrote:
On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara ircmax...@gmail.com
wrote:
Larry,
Anthony, can you expand here at all about
Dmitry
On Fri, Feb 20, 2015 at 9:25 AM, Dmitry Stogov dmi...@zend.com wrote:
On Fri, Feb 20, 2015 at 5:08 PM, Pierre Joye pierre@gmail.com wrote:
hi Dmitry,
On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov dmi...@zend.com wrote:
On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara
On 02/20/2015 06:28 PM, Anthony Ferrara wrote:
Considering I'm not targetting 7 (I've updated the RFC to hint this),
we can choose what to do later depending on the exceptions result
(whether to bypass execution in strict mode only, or for all calls).
Thanks for the insight Anthony
That
Larry,
On Fri, Feb 20, 2015 at 6:31 PM, Larry Garfield la...@garfieldtech.com wrote:
On 02/20/2015 06:28 PM, Anthony Ferrara wrote:
Considering I'm not targetting 7 (I've updated the RFC to hint this), we
can choose what to do later depending on the exceptions result (whether to
bypass
Robert,
On Fri, Feb 20, 2015 at 2:48 PM, Robert Stoll p...@tutteli.ch wrote:
Hi Dmitry and Anthony,
I was skimming through your conversation about JIT/AOT and that type hints
would allow to optimise few things.
I do not know if you are aware of the following but type hints can be passed
On Fri, Feb 20, 2015 at 3:36 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Larry,
On Fri, Feb 20, 2015 at 6:31 PM, Larry Garfield la...@garfieldtech.com
wrote:
On 02/20/2015 06:28 PM, Anthony Ferrara wrote:
Considering I'm not targetting 7 (I've updated the RFC to hint this), we
can
is welcome too.
Regards
François
-Message d'origine-
De : Anthony Ferrara [mailto:ircmax...@gmail.com]
Envoyé : vendredi 20 février 2015 02:58
À : Larry Garfield
Cc : internals@lists.php.net
Objet : Re: [PHP-DEV] Reviving scalar type hints
Larry,
Anthony, can you expand here
On 20 בפבר׳ 2015, at 16:55, Anthony Ferrara ircmax...@gmail.com wrote:
verification and static analysis aren't enough?
Anthony,
While IMHO they're not enough to warrant substantial deviation from PHP's
behavior, this is a subjective question that others might answer differently.
But
Zeev,
On Fri, Feb 20, 2015 at 10:24 AM, Zeev Suraski z...@zend.com wrote:
On 20 בפבר׳ 2015, at 16:55, Anthony Ferrara ircmax...@gmail.com wrote:
verification and static analysis aren't enough?
Anthony,
While IMHO they're not enough to warrant substantial deviation from PHP's
behavior,
On Feb 20, 2015 11:08 AM, Anthony Ferrara ircmax...@gmail.com wrote:
Zeev,
On Fri, Feb 20, 2015 at 10:24 AM, Zeev Suraski z...@zend.com wrote:
On 20 בפבר׳ 2015, at 16:55, Anthony Ferrara ircmax...@gmail.com wrote:
verification and static analysis aren't enough?
Anthony,
Larry,
Assume for a moment that:
- we tighten up the default passing rules, such that 32 passed to an int
works but 32 footsteps errors (which I thing most are on board with doing)
- we include a strict types mode as proposed, including the logical type
widening cases
- Zend Engine gets
On 02/20/2015 09:39 AM, Anthony Ferrara wrote:
I think if anything, the appearance of Hack (and its adoption) show
that people want static typing, at least to some level...
To be perfectly transparent here though, you should mention that your
proposed RFC goes well beyond the strict typing that
On Feb 20, 2015, at 10:30 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 02/20/2015 09:39 AM, Anthony Ferrara wrote:
I think if anything, the appearance of Hack (and its adoption) show
that people want static typing, at least to some level...
To be perfectly transparent here though, you
On Fri, Feb 20, 2015 at 9:26 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi Anthony,
On Fri, Feb 20, 2015 at 5:55 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
Dmitry
On Fri, Feb 20, 2015 at 9:25 AM, Dmitry Stogov dmi...@zend.com wrote:
On Fri, Feb 20, 2015 at 5:08 PM, Pierre Joye
Point of clarification: it exists in the RFC already:
https://wiki.php.net/rfc/scalar_type_hints_v5#internal_functions_should_opt-in_to_typing
On Fri, Feb 20, 2015 at 2:06 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Rasmus,
To be perfectly transparent here though, you should mention that
On 02/20/2015 10:52 AM, Josh Watzman wrote:
On Feb 20, 2015, at 10:30 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
Hack examples all using ?hh // strict
echo number_format('1000');
echo htmlspecialchars(1000);
echo md5(1000);
These are all fine both as far as the type-checker is
Rasmus,
To be perfectly transparent here though, you should mention that your
proposed RFC goes well beyond the strict typing that is in Hack because
in Hack the internal API is largely untyped while your proposal is to
default the entire internal API to strict types in strict mode. Also, in
Hi Dmitry and Anthony,
I was skimming through your conversation about JIT/AOT and that type hints
would allow to optimise few things.
I do not know if you are aware of the following but type hints can be passed
by. Hence neither weak or strict type hints allow to predict the type (even if
only
-Original Message-
From: Larry Garfield [mailto:la...@garfieldtech.com]
Sent: Thursday, February 19, 2015 9:00 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Reviving scalar type hints
On 02/17/2015 01:30 PM, Zeev Suraski wrote:
Yes, I already know that.
At this point
On 19/02/15 09:13, Zeev Suraski wrote:
Obviously, I think 'weak' campers have a lot to gain too - by making
sensible conversions work fine as expected, without having to resort to
explicit casts.
And everyone stands to gain from having just one mode, instead of two.
The coercive typing
@lists.php.net
Objet : Re: [PHP-DEV] Reviving scalar type hints
On 19/02/15 09:13, Zeev Suraski wrote:
Obviously, I think 'weak' campers have a lot to gain too - by making
sensible conversions work fine as expected, without having to resort to
explicit casts.
And everyone stands to gain from
-Original Message-
From: Lester Caine [mailto:les...@lsces.co.uk]
Sent: Thursday, February 19, 2015 12:24 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Reviving scalar type hints
On 19/02/15 09:13, Zeev Suraski wrote:
Obviously, I think 'weak' campers have a lot to gain
On 02/19/2015 04:13 AM, Zeev Suraski wrote:
-Original Message-
From: Larry Garfield [mailto:la...@garfieldtech.com]
Sent: Thursday, February 19, 2015 9:00 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Reviving scalar type hints
On 02/17/2015 01:30 PM, Zeev Suraski wrote:
Yes, I
On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara ircmax...@gmail.com
wrote:
Larry,
Anthony, can you expand here at all about the practical benefits of
strong-typing for variable passing for the compiler? That seems to be
the
main point of contention: Whether or not there are real,
On Thu, Feb 19, 2015 at 8:21 AM, Lester Caine les...@lsces.co.uk wrote:
On 19/02/15 12:52, Zeev Suraski wrote:
Now that all made sense!
My only grey area is 'allowing sensible ones' where the size is an
integral part
of what is 'sensible' ... the one where conventional strict typing uses
On 19/02/15 12:52, Zeev Suraski wrote:
Now that all made sense!
My only grey area is 'allowing sensible ones' where the size is an
integral part
of what is 'sensible' ... the one where conventional strict typing uses a
type
of the right size?
I think the guiding principal for these
On 19/02/15 12:47, François Laupretre wrote:
I didn't add restrictions specific to number representation in the draft
ruleset yet, becausen while I think that's an important point, I didn't have
time to study it in depth.
I know you're an expert on this as you continuously (rightly) raised
Hi Larry,
Thanks for trying to sort this out. This is very valuable work.
De : Larry Garfield [mailto:la...@garfieldtech.com]
Anthony, can you expand here at all about the practical benefits of
strong-typing for variable passing for the compiler?
I will let Anthony reply as the question is
Larry,
Anthony, can you expand here at all about the practical benefits of
strong-typing for variable passing for the compiler? That seems to be the
main point of contention: Whether or not there are real, practical benefits
to be had in the compiler of knowing that a call will be in strict
Hi!
So let's talk compromise.
Would leaving internal functions out of the picture at this stage
change you mind? This is effectively what Hack does, internal
functions are explicitly marked as coercible.
For me, the option that makes users remember which functions are
internal and which are
On 02/17/2015 12:48 AM, Sara Golemon wrote:
Don't mistake me for hack. -Sara
No one could ever mistake you for a hack, Sara. :-)
--Larry Garfield
(Sorry, it was just sitting there...)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 02/17/2015 01:30 PM, Zeev Suraski wrote:
Yes, I already know that.
The difference, and why I keep pointing that out, is that me and many
others
want strict typing for our own reasons (but still in its entirety instead
of as a
limited mode) and most of us don't even care if you getting weak
Hi!
2) PHP would benefit hugely from static analysis tools and compile-time
type-based optimizations, but those are only possible with code that is
strongly typed. Currently such tools do not really exist, but with
Is that really the case? Javascript has very good optimizing engine, and
On Tue, Feb 17, 2015 at 3:30 AM, Leigh lei...@gmail.com wrote:
On 17 February 2015 at 05:48, Sara Golemon poll...@php.net wrote:
We can sigh and tut about this not being the PHP way, but the script
author was the one who chose to enter into a tight contract, and the
script author, not you, is
Hi,
On Tue, Feb 17, 2015 at 6:50 PM, Zeev Suraski z...@zend.com wrote:
On 17 בפבר׳ 2015, at 18:32, Andrey Andreev n...@devilix.net wrote:
Hi,
On Tue, Feb 17, 2015 at 6:11 PM, Zeev Suraski z...@zend.com wrote:
If it gave both sides exactly what they wanted, how come it generated so
much
On 17/02/15 15:30, François Laupretre wrote:
Returning 'not-zero/empty' as true and 'zero' as false is one of the
natural things to use in PHP and I don't think any other language has
that flexibility?
You didn't read it right.
I was talking of conversions *from* bool, not *to* bool. (int
On 17/02/15 15:47, Anthony Ferrara wrote:
A static analyzer (one of the reasons people want strict) would error
there. The reason is that *at compile time* it can't reason about the
code well enough to determine if there's an error or not. You're
passing a string where you expect an int. Is
On 17/02/2015 15:47, Anthony Ferrara wrote:
If we want to add a numeric type as a virtual union of int and
float, that's one way to solve the concern. If we don't, we could also
allow widening primitive conversion (int - float). That wouldn't work
well with bigints, but would be fine in other
On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 02/16/2015 09:48 PM, Sara Golemon wrote:
Second, I should clarify that while the HHVM runtime performs
coersion, the hack type checker is strict. So my original statement
was inaccurate. As far as hack is
On 17 בפבר׳ 2015, at 18:32, Andrey Andreev n...@devilix.net wrote:
Hi,
On Tue, Feb 17, 2015 at 6:11 PM, Zeev Suraski z...@zend.com wrote:
If it gave both sides exactly what they wanted, how come it generated so
much objection?
Simply put, because it absolutely doesn't give both
De : Andrey Andreev [mailto:n...@devilix.net]
If we still see that employing the strict(er) rules is very noisy with
internal functions, a more appropriate option may be introducing new
types
into ZPP, that would correspond to the new rules we introduce in the
userland type hints, and
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Tuesday, February 17, 2015 5:48 PM
To: Zeev Suraski
Cc: franc...@php.net; Sara Golemon; PHP internals
Subject: Re: [PHP-DEV] Reviving scalar type hints
Zeev et al,
Because it
**wasn't** a compromise
On Tue, Feb 17, 2015 at 5:38 PM, Sara Golemon poll...@php.net wrote:
On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf ras...@lerdorf.com
wrote:
On 02/16/2015 09:48 PM, Sara Golemon wrote:
Second, I should clarify that while the HHVM runtime performs
coersion, the hack type checker is
On 02/17/2015 08:38 AM, Sara Golemon wrote:
On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
Please correct me here if I somehow ran these incorrectly. I did put
some deliberate type errors into my userspace code and hh_client caught
those nicely, so it seems like it
Hi,
On Tue, Feb 17, 2015 at 6:11 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Tuesday, February 17, 2015 5:48 PM
To: Zeev Suraski
Cc: franc...@php.net; Sara Golemon; PHP internals
Subject: Re: [PHP-DEV] Reviving
Am 17.02.2015 um 12:30 schrieb Leigh:
And you find taking authority over a library away from the library
author completely acceptable?
If I write an API that works perfectly well in strict mode, why
shouldn't I be able to turn strict on for my whole library? Do I just
tell users that
De : Zeev Suraski [mailto:z...@zend.com]
Even though that's not what I meant when I sent my proposal in the
morning,
Sorry, I was not clear enough : it was my position only.
I've been wondering about the same thing (also with the feedback from
Dmitry). Can go an extra step from both
Hi,
On Tue, Feb 17, 2015 at 5:02 PM, Dennis Birkholz den...@birkholz.biz wrote:
Am 17.02.2015 um 12:30 schrieb Leigh:
And you find taking authority over a library away from the library
author completely acceptable?
If I write an API that works perfectly well in strict mode, why
shouldn't I
On 17/02/15 14:49, Andrey Andreev wrote:
I agree. It's more of a question of eliminating potentially dangerous
conversions than just being lossless.
Agreed as well. However, while bool - int conversion one of the
reasons why many people want strict type-hints, it also often makes
sense
On Tue, Feb 17, 2015 at 1:30 PM, Leigh lei...@gmail.com wrote:
On 17 February 2015 at 05:48, Sara Golemon poll...@php.net wrote:
We can sigh and tut about this not being the PHP way, but the script
author was the one who chose to enter into a tight contract, and the
script author, not you, is
Hi,
On Tue, Feb 17, 2015 at 3:33 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: François Laupretre [mailto:franc...@php.net]
Sent: Tuesday, February 17, 2015 2:58 PM
To: 'Sara Golemon'; 'Zeev Suraski'
Cc: 'PHP internals'
Subject: RE: [PHP-DEV] Reviving scalar type
De : Lester Caine [mailto:les...@lsces.co.uk]
Returning 'not-zero/empty' as true and 'zero' as false is one of the
natural things to use in PHP and I don't think any other language has
that flexibility?
You didn't read it right.
I was talking of conversions *from* bool, not *to* bool. (int
Zeev et al,
2. It is not not about being lossless or not. People expect bool - int to
be
disabled, for example, and it is not lossless.
3. It is more a question of finding a consensus about conversions which
don't
make sense, and disabling them. Examples include bool conversion to any
-Original Message-
From: François Laupretre [mailto:franc...@php.net]
Sent: Tuesday, February 17, 2015 2:58 PM
To: 'Sara Golemon'; 'Zeev Suraski'
Cc: 'PHP internals'
Subject: RE: [PHP-DEV] Reviving scalar type hints
2. It is not not about being lossless or not. People expect bool
On Tue, Feb 17, 2015 at 7:02 AM, Dennis Birkholz den...@birkholz.biz wrote:
Am 17.02.2015 um 12:30 schrieb Leigh:
And you find taking authority over a library away from the library
author completely acceptable?
If I write an API that works perfectly well in strict mode, why
shouldn't I be
-Original Message-
From: Andrey Andreev [mailto:n...@devilix.net]
Sent: Tuesday, February 17, 2015 4:49 PM
To: Zeev Suraski
Cc: franc...@php.net; Sara Golemon; PHP internals
Subject: Re: [PHP-DEV] Reviving scalar type hints
Hi,
On Tue, Feb 17, 2015 at 3:33 PM, Zeev Suraski z
De : Lester Caine [mailto:les...@lsces.co.uk]
My current practice up until now has been to use 'return false' when an
action failed, but the main return would be a number of records or
string of data. So you are now blocking that activity ... I'm reading to
right, but you are not thinking
De : François Laupretre [mailto:franc...@php.net]
This way, the user can write :
function convertToInt(string $number): int! { - int! instead of int
if (!preg_match((^[0-9]{1,17}$), $number)) {
throw new InvalidArgumentException(Supplied argument is not a valid
Yes, I already know that.
The difference, and why I keep pointing that out, is that me and many
others
want strict typing for our own reasons (but still in its entirety instead
of as a
limited mode) and most of us don't even care if you getting weak typing
for
your own usage. You can't
I like 2) No possible confusion, and it's a clear tag.
I agree, but it feels like it gets away from PHP's underscore-heavy
syntax. The poll omitted ?php_strict -- that feels most PHP to me.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara
Golemon
1. Tighten up the type coercion for the 1000 dogs case although we
have to look at whether there is a problem with some database APIs
returning space-padded fields so 1000 would now break.
Hopefully
Boggiano [mailto:j.boggi...@seld.be]
Envoyé : mardi 17 février 2015 17:26
À : internals@lists.php.net
Objet : Re: [PHP-DEV] Reviving scalar type hints
On 17/02/2015 15:47, Anthony Ferrara wrote:
If we want to add a numeric type as a virtual union of int and
float, that's one way to solve
Le Tue, 17 Feb 2015 00:58:18 +0100, Sara Golemon poll...@php.net a écrit:
On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre franc...@php.net
wrote:
Once again, anyone can take over version 0.3, if it is so great. Why
don't you do it ?
I will play the game, stop working on my proposal, and
On 17 February 2015 at 05:48, Sara Golemon poll...@php.net wrote:
We can sigh and tut about this not being the PHP way, but the script
author was the one who chose to enter into a tight contract, and the
script author, not you, is the one who should have that authority over
their own
On 17/02/15 18:33, François Laupretre wrote:
What does this mean in your case ? Just that, as long as the feature is not
available, your function won't have an explicit return type. Period. And,
please, don't change false to 0 ;).
I simply can't see the case for limited function type hints
De : Lester Caine [mailto:les...@lsces.co.uk]
On 17/02/15 18:33, François Laupretre wrote:
What does this mean in your case ? Just that, as long as the feature is not
available, your function won't have an explicit return type. Period. And,
please, don't change false to 0 ;).
I simply
On 02/16/2015 09:48 PM, Sara Golemon wrote:
Second, I should clarify that while the HHVM runtime performs
coersion, the hack type checker is strict. So my original statement
was inaccurate. As far as hack is concerned, it's simply strict.
Period.
With both the default (partial) type
On 17/02/15 21:28, François Laupretre wrote:
De : Lester Caine [mailto:les...@lsces.co.uk]
On 17/02/15 18:33, François Laupretre wrote:
What does this mean in your case ? Just that, as long as the feature is not
available, your function won't have an explicit return type. Period. And,
On Tue, Feb 17, 2015 at 9:22 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 02/16/2015 09:48 PM, Sara Golemon wrote:
Second, I should clarify that while the HHVM runtime performs
coersion, the hack type checker is strict. So my original statement
was inaccurate. As far as hack is
On 02/17/2015 01:11 AM, Benjamin Eberlei wrote:
I think curl_setopt is a misleading example in the typehinting
discussion, because
this kind of API does not benefit from it. The third argument depends
on the second argument and requires a generic type in code:
curl_setopt(resource $ch, int
2015-02-17 0:58 GMT+01:00 Sara Golemon poll...@php.net:
On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre franc...@php.net
wrote:
Straw poll:
1) ?php strict;
2) ?php-strict
3) use strict; (psuedo-namespace)
4) ?php // strict (I don't actually like HHVM's style, but if you do...)
5)
On 17/02/15 06:20, Sara Golemon wrote:
* Typedefs (e.g. TypeDef (int|float) numeric; -- Some defined as
standard (like numeric), others user-definable)
And also ... int4, int8 and similar for correctly constrained values.
In an ideal world the whole SQL standard types would be available, but
On Mon, 16 Feb 2015, Sara Golemon wrote:
On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre franc...@php.net wrote:
Once again, anyone can take over version 0.3, if it is so great. Why don't
you do it ?
I will play the game, stop working on my proposal, and vote 'yes' again.
But don't
Hi Sara,
De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara
Golemon
So, if you'll permit me to summarize your message. The following
would be palatable to you?
* Lossless coercion. This would sit somewhere between strict types
and weak types as lossy conversions
Hi,
De : Arvids Godjuks [mailto:arvids.godj...@gmail.com]
The 0.1 RFC version was mentioned a lot as a good compromise by many
people
and had major support.
Maybe someone competent could pick it up, make necessary adjustments
that
where required and let people vote on it? Start with
On 16 February 2015 at 16:42, François Laupretre franc...@php.net wrote:
Hi,
De : Arvids Godjuks [mailto:arvids.godj...@gmail.com]
The 0.1 RFC version was mentioned a lot as a good compromise by many
people
and had major support.
Maybe someone competent could pick it up, make
On Mon, Feb 16, 2015 at 7:42 PM, François Laupretre franc...@php.net
wrote:
Hi,
De : Arvids Godjuks [mailto:arvids.godj...@gmail.com]
The 0.1 RFC version was mentioned a lot as a good compromise by many
people
and had major support.
Maybe someone competent could pick it up, make
Hi,
De : morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] De la part
Also, I know people REALLY want scalar types in PHP 7.0 but honestly
all we need to do is reserve the keywords so there is no BC impact and
then we can do it at any point during the PHP 7 lifecycle. This is my
On Mon, Feb 16, 2015 at 5:42 PM, François Laupretre franc...@php.net wrote:
Hi,
- the fact that the RFC supports single types only, like the previous 'return
type' RFC. While it is easier to implement, it opens several issues as
multiply-typed arguments are an integral part of the PHP
On Mon, Feb 16, 2015 at 9:42 AM, François Laupretre franc...@php.net wrote:
Hi,
De : Arvids Godjuks [mailto:arvids.godj...@gmail.com]
The 0.1 RFC version was mentioned a lot as a good compromise by many
people
and had major support.
Maybe someone competent could pick it up, make necessary
Hi Dmitry
De : Dmitry Stogov [mailto:dmi...@zend.com]
I would propose exactly Andrea's 0.1.
Most people were agree to support weak type hints by default.
This proposal won't prevent feature addition of optional strict type hints.
All are tired from endless arguing.
Yes, but that's not
On Mon, Feb 16, 2015 at 9:50 PM, François Laupretre franc...@php.net wrote:
De : Pavel Kouril [mailto:pajou...@gmail.com]
Hello,
I know this is probably a pretty unpopular opinion in PHP (based on
the replies I got in the other thread), but different values for
parameters should be IMHO
De : Philip Sturgeon [mailto:pjsturg...@gmail.com]
I know it is very easy for people to say Well, that v0.3 that I
didn't like has been withdrawn, so let's just crack on and do some
other new thing.
It's not so easy. It would be easier to do as you suggest. And you can still do
it in your
De : Pavel Kouril [mailto:pajou...@gmail.com]
Hello,
I know this is probably a pretty unpopular opinion in PHP (based on
the replies I got in the other thread), but different values for
parameters should be IMHO solved by method overloading and such.
The question is not that it's
On 16 February 2015 at 22:00, Philip Sturgeon pjsturg...@gmail.com wrote:
I know it is very easy for people to say Well, that v0.3 that I
didn't like has been withdrawn, so let's just crack on and do some
other new thing. but I would have to ask people to consider that v0.3
had two thirds
-Original Message-
From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
Golemon
Sent: Tuesday, February 17, 2015 1:58 AM
To: franc...@php.net
Cc: Philip Sturgeon; Arvids Godjuks; Jefferson Gonzalez; Rowan Collins;
PHP
internals
Subject: Re: [PHP-DEV] Reviving scalar
Hi,
On Mon, Feb 16, 2015 at 8:56 PM, Dmitry Stogov dmi...@zend.com wrote:
I would propose exactly Andrea's 0.1.
Most people were agree to support weak type hints by default.
This proposal won't prevent feature addition of optional strict type hints.
Sorry, but I'll have to repeat what has
Am 16.02.2015 um 21:39 schrieb François Laupretre:
If we deprecate using bare class names as type hints and replace it with the
'object(classname)' syntax, we can reserve keywords for 7.0 and, maybe 7.1
but potential name clashes should be away in 7.2.
This is a huge BC break and will
Le 16/02/2015 23:50, François Laupretre a écrit :
So, IMO, the RFC is dead, whatever 2/3 or 3/4 we may have.
Once it was clear that both camps would never agree, with every PHP
founders against it, pushing it was useless. We're not electing a
president, we're trying to ensure we make the right
1 - 100 of 114 matches
Mail list logo
