Hi Zeev,
> On 15 Jan 2015, at 14:32, Zeev Suraski wrote:
>
>> Whether or not they are in the majority, a very large portion of PHP
>> developers would prefer strict typing. In particular, the most vocal ones
>> would seem to. There are also a lot of PHP developers who would prefer
>> weak typing
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Thursday, January 15, 2015 4:10 PM
> To: Zeev Suraski
> Cc: rquadl...@gmail.com; Leigh; PHP Internals List
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
>
> Hi Zeev,
>
> Whether o
Hey Rowan,
> On 15 Jan 2015, at 13:02, Rowan Collins wrote:
>
> Zeev Suraski wrote on 15/01/2015 11:56:
>> PLUS have the ability to radically
>> change how it behaves based on a runtime option. It's so bad that we
>> decided more than a decade ago that we want to refrain from ever introducing
>
Hi Zeev,
> On 15 Jan 2015, at 11:56, Zeev Suraski wrote:
>
> Andrea,
>
> I'm not sure what you're basing that assumption on. The incidental
> interactions you (or anybody) may have with 'the community', by no way
> represent the opinion of the community at large. The vast majority of the
> PH
Hi Stas,
> On 14 Jan 2015, at 23:29, Stanislav Malyshev wrote:
>
> I agree. Being wrong is bad, making a mistake is bad, but having split
> personality language and not knowing in which world you are - or even
> worse, having to deal with both worlds in the same code and being thrown
> back and
Zeev Suraski wrote on 15/01/2015 11:56:
PLUS have the ability to radically
change how it behaves based on a runtime option. It's so bad that we
decided more than a decade ago that we want to refrain from ever introducing
such elements to PHP again (e.g. magic_quotes_runtime), and I'm not sure wh
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Thursday, January 15, 2015 12:29 AM
> To: Zeev Suraski
> Cc: rquadl...@gmail.com; Leigh; PHP Internals List
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
>
> Hi Zeev,
>
> &g
Hey:
On Thu, Jan 15, 2015 at 6:42 AM, Andrea Faulds wrote:
> Hey Dmitry,
>
>> On 14 Jan 2015, at 20:40, Dmitry Stogov wrote:
>>
>> In my opinion, version 0.1 was consistent enough.
>>
>> handling two different approaches just makes mess...
>>
>> We have internal function strlen(string $s), and i
On
15
Jan
2015,
at
0:33, Andrea Faulds :
Hi Marcio,
> On 14 Jan 2015, at 18:52, Marcio Almada wrote:
>
> We still have a BC break but now we also have code with **mutant**
behavior that might become buggy (do unexpected things) if a `declare` is
used. As a language user and a package mainta
On 15/01/15 08:49, Pavel Kouřil wrote:
>> One of the nice features of PHP when I started using it all those years
>> > ago was that I did not have to create separate functions different types
>> > did exist in the source data. int/float/num/double and others all needed
>> > separate handling in c/c
On Thu, Jan 15, 2015 at 9:29 AM, Lester Caine wrote:
>
> One of the nice features of PHP when I started using it all those years
> ago was that I did not have to create separate functions different types
> did exist in the source data. int/float/num/double and others all needed
> separate handling
On 15/01/15 07:26, Pavel Kouřil wrote:
> And yesterday I was pointed out one thing: the RFC states "With this
> approach, an argument is only accepted if its type is exactly the same
> as the parameter.". Does this mean you cannot pass integer to a
> function with float argument in the strict mode?
> On Wed, Jan 14, 2015 at 11:28 PM, Andrea Faulds wrote:
> From what I can see, the larger PHP community is generally in favour of
> strict typing, and among them, the previous RFC revision was received quite
> poorly. Myself, I might have been somewhat happy with just weak hints, but it
> woul
Andrea Faulds wrote:
> From what I can see, the larger PHP community is generally in favour
> of strict typing, and among them, the previous RFC revision was
> received quite poorly. Myself, I might have been somewhat happy with
> just weak hints, but it would upset an awful lot of developers who
hi Andrea,
On Wed, Jan 14, 2015 at 1:16 AM, Andrea Faulds wrote:
> Good evening,
>
> I’ve made some quite significant changes to my Scalar Type Hints RFC, and
> bumped its version to 0.2.
>
> Here: https://wiki.php.net/rfc/scalar_type_hints
>
> This is a new thread because I’ve made a significan
Hi!
> We’re definitely not going to have consensus on introducing both options as
> per this RFC. I for one think it’s the worst possible option.
I agree. Being wrong is bad, making a mistake is bad, but having split
personality language and not knowing in which world you are - or even
worse, ha
Hey Dmitry,
> On 14 Jan 2015, at 20:40, Dmitry Stogov wrote:
>
> In my opinion, version 0.1 was consistent enough.
>
> handling two different approaches just makes mess...
>
> We have internal function strlen(string $s), and it may be called with
> integer argument e.g. strlen(123) -> 3
> I t
Hi Marc,
> On 14 Jan 2015, at 19:01, Marc Bennewitz wrote:
>
> 1. Inconsistencies of ZPP and explicit casts
>
> In my opinion it should be the same if you call a function in weak type mode
> and calling a function in strict type mode with explicit cast.
>
> But that would require to remove in
Hi Marcio,
> On 14 Jan 2015, at 18:52, Marcio Almada wrote:
>
> We still have a BC break but now we also have code with **mutant** behavior
> that might become buggy (do unexpected things) if a `declare` is used. As a
> language user and a package maintainer it would be a huge problem. Imagine
Hi Rowan,
> On 14 Jan 2015, at 15:45, Rowan Collins wrote:
>
> Perhaps it would be clearer if the RFC (and the documentation, if this is
> accepted) referred to the non-strict as something other than "weak". It makes
> it sound like only a weak check will be performed, and some values of the
Hi Zeev,
> On 14 Jan 2015, at 13:35, Zeev Suraski wrote:
>
> I don’t think we’re ever going to get consensus. But judging by the feedback
> to the v0.1 version, I tend to disagree that the opposers would have blocked
> it. There were certainly opposers – but not that many of them as far as I
In my opinion, version 0.1 was consistent enough.
handling two different approaches just makes mess...
We have internal function strlen(string $s), and it may be called with
integer argument e.g. strlen(123) -> 3
I think user functions should follow the same rules.
If some rules are "bad", lets
Hi Andrea,
I have some notes about this RFC from a users POV with only little
knowledge about internals.
I didn't read 100% of the theads of this RFC so I'm sorry if some notes
of this email was already discussed.
1. Inconsistencies of ZPP and explicit casts
In my opinion it should be the s
, -1 here
2015-01-14 5:22 GMT-03:00 Robert Stoll :
> Hi Andrea
>
> > -Ursprüngliche Nachricht-
> > Von: Andrea Faulds [mailto:a...@ajf.me]
> > Gesendet: Mittwoch, 14. Januar 2015 01:17
> > An: PHP Internals List
> > Betreff: [PHP-DEV] [RFC] Scalar
Andrea Faulds wrote on 14/01/2015 13:15:
Hi Thomas,
On 14 Jan 2015, at 13:04, Thomas Nunninger wrote:
Sorry, if my mail was not clear. My point was: If I write a library in strict
mode and someone else is using it from his non-strict mode, he can pass an
integer to myFunc() without an error
On 14 January 2015 at 14:00, Pavel Kouřil wrote:
>
>
> PS: Personally, I find the "scalar" typehint idea useless and cannot
> find a real use case for it. Richard, would you mind giving an
> example?
>
The point of the 'scalar' typehint comes about because we need to reject
non compatible types.
2015-01-14 16:00 GMT+02:00 Pavel Kouřil :
> Hello,
>
> personally, as a language user, I really dislike the idea of both
> options for scalar type hinting to be the part of the language.
> Especially since you would have to declare the strict typing in each
> file (if you are going by 1 class per
On 01/14/2015 02:35 PM, Zeev Suraski wrote:
> I don’t think we’re ever going to get consensus. But judging by the
> feedback to the v0.1 version, I tend to disagree that the opposers would
> have blocked it. There were certainly opposers – but not that many of them
> as far as I could tell. I
> *Sent:* Wednesday, January 14, 2015 3:23 PM
> *To:* Zeev Suraski
> *Cc:* Andrea Faulds; Leigh; PHP Internals List
> *Subject:* Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
>
>
>
>
>
>
>
> On 14 January 2015 at 09:41, Zeev Suraski wrote:
>
>> -Orig
option.
Zeev
*From:* Richard Quadling [mailto:rquadl...@gmail.com]
*Sent:* Wednesday, January 14, 2015 3:23 PM
*To:* Zeev Suraski
*Cc:* Andrea Faulds; Leigh; PHP Internals List
*Subject:* Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
On 14 January 2015 at 09:41, Zeev Suraski wrote
On 14 January 2015 at 09:41, Zeev Suraski wrote:
> > -Original Message-
> > From: Andrea Faulds [mailto:a...@ajf.me]
> > Sent: Wednesday, January 14, 2015 11:33 AM
> > To: Leigh
> > Cc: PHP Internals List
> > Subject: Re: [PHP-DEV] [RFC] Sca
Hi Thomas,
> On 14 Jan 2015, at 13:04, Thomas Nunninger wrote:
>
> Sorry, if my mail was not clear. My point was: If I write a library in strict
> mode and someone else is using it from his non-strict mode, he can pass an
> integer to myFunc() without an error. If I use this integer in my libr
Hi Andrea,
On 01/14/2015 11:20 AM, Andrea Faulds wrote:
Hi Thomas,
On 14 Jan 2015, at 10:08, Thomas Nunninger wrote:
$i = 1;
$a = myFunc( $i );
declare(strict_typehints=TRUE);
function myFunc( float $f )
{
return otherFunc( $f );
}
function otherFunc( float $f )
{
Hi again,
On Wed, Jan 14, 2015 at 1:21 PM, Andrea Faulds wrote:
> Hi Andrey,
>
>> On 14 Jan 2015, at 11:10, Andrey Andreev wrote:
>>
>> I don't understand why it should be a bad thing that the API author
>> forces rules on the consumer. The opposite is IMO fundamental to the
>> concept of an API
Hi Andrey,
> On 14 Jan 2015, at 11:10, Andrey Andreev wrote:
>
> I don't understand why it should be a bad thing that the API author
> forces rules on the consumer. The opposite is IMO fundamental to the
> concept of an API - the rules specified by the author are a contract
> that the consumer a
Hello,
On Wed, Jan 14, 2015 at 12:22 PM, Andrea Faulds wrote:
>
> Hi Julien,
>
>> On 14 Jan 2015, at 10:14, Julien Pauli wrote:
>>
>> Using declare() IMO, is a PITA.
>> Everything that can be done without the use of declare(), must be done
>> without declare().
>>
>> I would have prefered diffe
Hi Julien,
> On 14 Jan 2015, at 10:14, Julien Pauli wrote:
>
> Using declare() IMO, is a PITA.
> Everything that can be done without the use of declare(), must be done
> without declare().
>
> I would have prefered different syntax, like the ones we disccussed many
> years ago , having stric
Hi Thomas,
> On 14 Jan 2015, at 10:08, Thomas Nunninger wrote:
>
>
> $i = 1;
> $a = myFunc( $i );
>
> declare(strict_typehints=TRUE);
>
> function myFunc( float $f )
> {
>return otherFunc( $f );
> }
>
> function otherFunc( float $f )
> {
>...
> }
>
>
On Wed, Jan 14, 2015 at 1:16 AM, Andrea Faulds wrote:
> Good evening,
>
> I’ve made some quite significant changes to my Scalar Type Hints RFC, and
> bumped its version to 0.2.
>
> Here: https://wiki.php.net/rfc/scalar_type_hints
>
> This is a new thread because I’ve made a significant revision t
Hi,
On 01/14/2015 10:32 AM, Andrea Faulds wrote:
Hi Leigh,
On 14 Jan 2015, at 09:17, Leigh wrote:
I really don't like this behaviour being changed at the call site. If
I design a function that I _know_ should only take a string, then I
want it to be an error if the user supplies anything els
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Wednesday, January 14, 2015 11:33 AM
> To: Leigh
> Cc: PHP Internals List
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
>
> Hi Leigh,
>
> > On 14 Jan 2015, at 09:17, Leigh w
Hi Leigh,
> On 14 Jan 2015, at 09:17, Leigh wrote:
>
> I really don't like this behaviour being changed at the call site. If
> I design a function that I _know_ should only take a string, then I
> want it to be an error if the user supplies anything else, so that
> they know they messed up.
I d
On 14 January 2015 at 00:16, Andrea Faulds wrote:
> Good evening,
>
> I’ve made some quite significant changes to my Scalar Type Hints RFC, and
> bumped its version to 0.2.
>
> Here: https://wiki.php.net/rfc/scalar_type_hints
>
> This is a new thread because I’ve made a significant revision to th
Hey Robert,
> On 14 Jan 2015, at 08:22, Robert Stoll wrote:
>
> I had a few thoughts on the new proposed declare(strict_typehints=TRUE);
> construct and I must say I do not really like that we would have different
> behaviour just based on a directive. This is quite ugly from a readability
>
Hi Andrea
> -Ursprüngliche Nachricht-
> Von: Andrea Faulds [mailto:a...@ajf.me]
> Gesendet: Mittwoch, 14. Januar 2015 01:17
> An: PHP Internals List
> Betreff: [PHP-DEV] [RFC] Scalar Type Hints v0.2
>
> Good evening,
>
> I’ve made some quite significant chan
Good evening,
I’ve made some quite significant changes to my Scalar Type Hints RFC, and
bumped its version to 0.2.
Here: https://wiki.php.net/rfc/scalar_type_hints
This is a new thread because I’ve made a significant revision to the RFC, so
it’d be sensible to separate discussion of the update
101 - 146 of 146 matches
Mail list logo