Good evening,
I’ve given up on my plan B, so I’m putting this RFC, finally, to a vote.
I would urge you to vote in favour. It is not going to please everyone, it is
after all a compromise proposal. However, I have tried my best to strike a
balance between complete weak typing and strict typing.
On 14 Sep 2014, at 00:30, Andrea Faulds wrote:
> Good evening,
>
> I’ve given up on my plan B, so I’m putting this RFC, finally, to a vote.
>
> I would urge you to vote in favour. It is not going to please everyone, it is
> after all a compromise proposal. However, I have tried my best to stri
On Sun, Sep 14, 2014 at 12:30:40AM +0100, Andrea Faulds wrote:
> Good evening,
>
> I’ve given up on my plan B, so I’m putting this RFC, finally, to a vote.
>
> I would urge you to vote in favour. It is not going to please everyone, it is
> after all a compromise proposal. However, I have tried m
On 14 Sep 2014, at 01:07, Alain Williams wrote:
> You give an option for float to int casting to truncate.
Where?
oa-res-27-90:php-src ajf$ sapi/cli/php -r 'function foobar(int $a) {
var_dump($a); } foobar(1.5);'
Catchable fatal error: Argument 1 passed to foobar() must be of the
Hi!
> oa-res-27-90:php-src ajf$ sapi/cli/php -r 'function foobar(int $a) {
> var_dump($a); } foobar(1.5);'
>
> Catchable fatal error: Argument 1 passed to foobar() must be of the
> type int, float given, called in Command line code on line 1 and
> defined in Command line code on line 1
Calling t
hi Andrea,
On Sun, Sep 14, 2014 at 1:30 AM, Andrea Faulds wrote:
> Good evening,
>
> I’ve given up on my plan B, so I’m putting this RFC, finally, to a vote.
>
> I would urge you to vote in favour. It is not going to please everyone, it is
> after all a compromise proposal. However, I have tried
On Sun, Sep 14, 2014 at 01:10:20AM +0100, Andrea Faulds wrote:
>
> On 14 Sep 2014, at 01:07, Alain Williams wrote:
>
> > You give an option for float to int casting to truncate.
>
> Where?
Possible Changes
Float to Int Casting Rules
...
This could be relaxed for semi-representab
On Sun, Sep 14, 2014 at 11:12 AM, Alain Williams wrote:
> On Sun, Sep 14, 2014 at 01:10:20AM +0100, Andrea Faulds wrote:
>>
>> On 14 Sep 2014, at 01:07, Alain Williams wrote:
>>
>> > You give an option for float to int casting to truncate.
>>
>> Where?
>
> Possible Changes
>
> Float to In
> From: a...@ajf.me
> Date: Sun, 14 Sep 2014 00:30:40 +0100
> To: internals@lists.php.net
> Subject: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
>
> Good evening,
>
> I’ve given up on my plan B, so I’m putting this RFC, finally, to a vote.
>
> I would urg
> On 14 Sep 2014, at 07:32, Stas Malyshev wrote:
>
> Calling this "scalar type hinting with cast" when it doesn't actually
> cast in wide variety of cases sounds a bit misleading to me. It should
> be called "scalar type checking with restricted casting" or something
> like that.
I'd agree it's
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Sunday, September 14, 2014 3:08 PM
> To: Stas Malyshev
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
>
>
> The problem is that we *can
On 14 Sep 2014, at 13:17, Zeev Suraski wrote:
> I honestly don't see why we can't be consistent for the simple types, or
> at least strive to be as consistent as possible as opposed to introducing
> a complete parallel universe for userland functions, that's inconsistent
> with the entirety of t
Hi,
As a userland guy, I'm against this one.
It seems a bit political ... A lot of people want either strict type
hints or type casting hints, but because the people on this list can't
get to agree on any of the two, this RFC tries to make a compromise
that, IMO, satisfies nobody. It's done not f
On 14 Sep 2014, at 15:56, Andrey Andreev wrote:
> It seems a bit political ... A lot of people want either strict type
> hints or type casting hints, but because the people on this list can't
> get to agree on any of the two, this RFC tries to make a compromise
> that, IMO, satisfies nobody. It'
Hi,
On Sun, Sep 14, 2014 at 6:09 PM, Andrea Faulds wrote:
>
> On 14 Sep 2014, at 15:56, Andrey Andreev wrote:
>
>> It seems a bit political ... A lot of people want either strict type
>> hints or type casting hints, but because the people on this list can't
>> get to agree on any of the two, thi
On 14 Sep 2014, at 16:40, Andrey Andreev wrote:
> ... and I responded to this in the next paragraph. Userland doesn't
> case about internal differences, that's why they're called internal
> and why people outside of php-internals have for so long been puzzled
> why we only have array and object
On Sun, Sep 14, 2014 at 6:47 PM, Andrea Faulds wrote:
>
> On 14 Sep 2014, at 16:40, Andrey Andreev wrote:
>
>> ... and I responded to this in the next paragraph. Userland doesn't
>> case about internal differences, that's why they're called internal
>> and why people outside of php-internals have
On 14 Sep 2014, at 17:09, Andrey Andreev wrote:
> I'm aware of that, hence why I said 'php-internals' to refer to the
> mailing list. Again, userland devs don't care about that - PHP is
> their language and they only care how we/they interact with it, not
> what happens under the hood.
Yes. Int
On Sun, Sep 14, 2014 at 7:17 PM, Andrea Faulds wrote:
>
> On 14 Sep 2014, at 17:09, Andrey Andreev wrote:
>
>> I'm aware of that, hence why I said 'php-internals' to refer to the
>> mailing list. Again, userland devs don't care about that - PHP is
>> their language and they only care how we/they
Hi Andrea,
When you re-open the voting, please can you have an option that is
'Yes - without numeric typehint' ?
Although I like the idea of the RFC, having a type-hint that matches
multiple scalar types seems distinctly weird to me.
It really needs a separate case making for it, separate from t
On 14 Sep 2014, at 18:23, Dan Ackroyd wrote:
> When you re-open the voting, please can you have an option that is
> 'Yes - without numeric typehint’ ?
I was already planning that, actually. :)
> Although I like the idea of the RFC, having a type-hint that matches
> multiple scalar types seems
Hi!
> The vote would be for the RFC as it is. Possible changes are things
> in the RFC I was uncertain on. I might hold votes on some of them,
> actually.
I'm sorry, but this makes little sense to me. There are a number of
mutually contradictory options here, how you can vote for them "as it
is"?
On 14 Sep 2014, at 18:29, Stas Malyshev wrote:
> Hi!
>
>> The vote would be for the RFC as it is. Possible changes are things
>> in the RFC I was uncertain on. I might hold votes on some of them,
>> actually.
>
> I'm sorry, but this makes little sense to me. There are a number of
> mutually co
Hi!
> The “possible changes” section only details possible *changes*, that
> is, changes to the RFC that could be made, but have not been. So you
OK, so by "possible changes" you mean things that could have been into
RFC, but were rejected and are not part of the RFC? Then I agree it is
clear but
On 14 Sep 2014, at 18:34, Stas Malyshev wrote:
> Hi!
>
>> The “possible changes” section only details possible *changes*, that
>> is, changes to the RFC that could be made, but have not been. So you
>
> OK, so by "possible changes" you mean things that could have been into
> RFC, but were reje
On 14/09/2014 17:41, Andrey Andreev wrote:
Perhaps I should explain what an “internal function” is in PHP parlance. An
internal function is one which is exposed to userland, but is implemented in C
via an extension, rather than in PHP. Examples include literally every function
in PHP’s documen
On Sep 14, 2014 8:21 PM, "Rowan Collins" wrote:
> As Andrea points out, one of the big problems in this discussion is that
those internal functions aren't actually consistent with one another - some
of the logic is built into zned_parse_parameters, but fallback behaviour
and additional checks are
Hello Andrea,
I find the rfc a bit difficult to understand:
e.g. is_float('1') gives false, but foo('1') with function foo(float $a){} is
ok.
Regards,
Thomas
Andrea Faulds wrote on 14.09.2014 01:30:
> Good evening,
>
> I’ve given up on my plan B, so I’m putting this RFC, finally, to a vote.
On Sun, 14 Sep 2014, Andrea Faulds wrote:
>
> On 14 Sep 2014, at 13:17, Zeev Suraski wrote:
>
> > I honestly don't see why we can't be consistent for the simple
> > types, or at least strive to be as consistent as possible as opposed
> > to introducing a complete parallel universe for userlan
On 14 Sep 2014, at 21:22, Derick Rethans wrote:
> But this "compromise" introduces yet another set of casting rules. And
> that is why will advocate and vote against this.
>
> We can either have casting where:
>
> function bar(int $foo) { }
> bar("42");
>
> Means the same as:
>
On 14/09/2014 21:22, Derick Rethans wrote:
Or we can have it as a strict cast, or we can have it like it currently
(ie, not at all). I can live with those three options, but not an
option where casting/checking does something different again.
Is there an existing, documented, definition of "str
On 14/09/2014 20:01, Pierre Joye wrote:
One side wants to be consistent with inconsistencies (and tbh quite
confusing) while the other side wants to allow userland implemented
APIs to actually be consistent.
I'm not sure that's quite fair. The only thing that would be consistent
with existing
On Sun, Sep 14, 2014 at 3:22 PM, Derick Rethans wrote:
> We can either have casting where:
>
> function bar(int $foo) { }
> bar("42");
>
> Means the same as:
>
> function bar($foo) { }
> bar((int) "42");
>
> Or we can have it as a strict cast, or we can have it like
Hi!
> This is exactly the issue we are battling here. One side wants to be
> consistent with inconsistencies (and tbh quite confusing) while the other
> side wants to allow userland implemented APIs to actually be consistent.
It's not the issue here. Nobody wants 100% of functions to do the same,
Stas Malyshev wrote (on 15/09/2014):
It's not the issue here. Nobody wants 100% of functions to do the same,
and everybody knows there will be exceptions when some functions can not
accept all values covered by type, or can accept multiple types but only
in certain situations, etc. etc. What we w
On 14 Sep 2014, at 00:35, Andrea Faulds wrote:
> I have postponed the vote after further thought. It’s been a while since this
> was discussed on the list.
>
> However, it is my intent to open voting properly at some point soon, if all
> goes to plan.
I have withdrawn the RFC. I do not feel
Am 14.09.2014 um 01:30 schrieb Andrea Faulds:
> https://wiki.php.net/rfc/scalar_type_hinting_with_cast
If I understand the "Syntax" section correctly, then int, float, numeric,
bool, and string are added as new reserved words (keywords). This would
break existing code, for instance userland cla
On 15 Sep 2014, at 17:42, Sebastian Bergmann wrote:
> Am 14.09.2014 um 01:30 schrieb Andrea Faulds:
>> https://wiki.php.net/rfc/scalar_type_hinting_with_cast
>
> If I understand the "Syntax" section correctly, then int, float, numeric,
> bool, and string are added as new reserved words (keyword
Am 15.09.2014 um 18:45 schrieb Andrea Faulds:
> Why are you looking at the initial commit from two years ago?
Sorry, my bad. No idea how that I happened, I should have looked at
http://bit.ly/1AQLqdD instead. And in there I see rules such as
%token T_STRING_TYPE
that introduce new reserved
Hi!
> I agree that 100% is an unrealistic goal, but I don't think I've yet
> seen someone actually point at a documented set of rules that even 80%
> of current functions follow. I guess there is a default/normal usage of
The rules are in zpp, and every function that uses zpp automatically
fol
Stas Malyshev wrote (on 15/09/2014):
Hi!
I agree that 100% is an unrealistic goal, but I don't think I've yet
seen someone actually point at a documented set of rules that even 80%
of current functions follow. I guess there is a default/normal usage of
The rules are in zpp, and every function
Sebastian Bergmann wrote (on 15/09/2014):
In any case, I think it would be best to build on the great work Nikita
did with the AST-based parser for PHP 7 and refactor the compiler to
allow reserved words as names for namespaces, classes, interfaces, ...
*before* we introduce new reserved
hi Andrea,
On Mon, Sep 15, 2014 at 3:07 PM, Andrea Faulds wrote:
>
> On 14 Sep 2014, at 00:35, Andrea Faulds wrote:
>
>> I have postponed the vote after further thought. It’s been a while since
>> this was discussed on the list.
>>
>> However, it is my intent to open voting properly at some poi
Hello,
thinking a bit again on the whole topic, which I thought I was pretty much
completely opposed to because of the arbitrary-new-set-of-rules issue in
die validation details, I noticed that from my writing PHP code, there _is_
a single thing that I really _would_ like to be able to express as
Hi!
> - One about having scalar typed arguements, hinted or not, simple
> yes/no, so we at least agree on having the feature
I'm not sure how that would work. We agree on having what feature?
Having coercive typing and having strict typing are two different
options, working in different way and i
On Sep 22, 2014 11:06 PM, "Stas Malyshev" wrote:
>
> Hi!
>
> > - One about having scalar typed arguements, hinted or not, simple
> > yes/no, so we at least agree on having the feature
>
> I'm not sure how that would work. We agree on having what feature?
> Having coercive typing and having strict
Hi!
> Most?
>
> Python has it, java too, ruby and perl not. We can continue to list
> those having them or not, not sure that brings much to this discussion.
Only Python 3 has it, and I'm not sure bringing up Python 3, given its
known adoption issues, is the best example how we could plan PHP 7.
47 matches
Mail list logo
