subject:"\[PHP\-DEV\] \[VOTE\] Scalar Type Hints"

Hi,

 On 12 Feb 2015, at 07:05, Pavel Kouřil pajou...@gmail.com wrote:
 
 On Thu, Feb 12, 2015 at 1:13 AM, Andrea Faulds a...@ajf.me wrote:
 
 A number (or numeric, or num, or some other name) type hint is something I 
 plan to propose in a future, follow-up RFC.
 
 
 wouldn't polymorphism (via method overloading) solve the use cases and
 be much more useful in the long run than introducing a something
 that's not a type into type hints?

PHP already has polymorphism through its dynamic typing. I don’t see method 
overloading happening any time soon. We have optional parameters and dynamic 
typing, which all but eliminate the main needs for overloading. We’re a 
weakly-typed language, so overloading on scalar types might cause unpredictable 
behaviour (with strict types you’d get an error sometimes, and that’s fine - 
but calling an entirely different function? Now that’s different.) There’s also 
the question of how, or if at all, method overloading could interact with our 
optional parameters and dynamic typing. Finally, overloading can lead to really 
poor API design: it’s not that uncommon in some languages to see 20 different 
function definitions with overlapping and non-comprehensive subsets of a 
method’s behaviour, that are distinguished only by parameter types. It’s one of 
my least favourite Java/C#/C++ features for that reason.

In response to saying numbers are not a type: well, they are more of an 
abstract type which integer and float subclass. We already have internal 
facilities for converting to and from “numbers” alongside integers and floats, 
I don’t see why we can’t expose this to users.

Thanks.
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-12 Thread Dennis Birkholz

Hello François,

 For a set of 'extended' types like 'number', and their matching rules against 
 zvals, this may help :
 
 https://wiki.php.net/rfc/dbc#dbc_types_vs_zval_types

I did not follow the DoC-discussion so far but from a quick glance at
the list there are at least cases that need a further look:

1. There is no float (without !) in the list. It should be IS_LONG = yes
(if value does not exceed float boundaries), IS_DOUBLE = yes and
IS_STRING = yes (same as for IS_LONG).

2. callable is missing a check for objects that contain __invoke() which
is also a valid callable.

Greets
Dennis Birkholz

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

RE: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-12 Thread Zeev Suraski

 @Zeev: I don't like being used, singling out only my blog post because it
 proves your opinion, where clearly there were other posts in favour of
 strict
 mode typing, for exampl e ircmaxell his.

Benjamin,

As we discussed in personal exchanges, I really don't think I 'used' you and
it certainly wasn't my intent.  I thought your blog, as well as Rasmus'
comments, did a good job at illustrating the shortcomings of the current RFC
with real world examples - and thought (and still think) it would be a good
idea for others to read it.  FWIW, when people link to blog posts of mine as
a recommended read I view this as a compliment, never as a negative thing.
I didn't agree with the points made in Anthony's blog so I didn't link to
it, but obviously, proponents of the current RFC are free to do so and did
so.

 You are not doing your opinion a
 good service imho, by being so obviously political about this issue.

I'm really not obviously or otherwise 'political' about this issue.  We're
dealing with technology here.  Much like Andrea, Anthony and others
genuinely believe that this RFC is good for PHP - me and many others believe
it's bad for PHP.

Thanks,

Zeev

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hi Pavel,

 On 12 Feb 2015, at 13:48, Pavel Kouřil pajou...@gmail.com wrote:
 
 C# does have dynamic typing.

No it doesn’t, it’s a statically-typed language. I don’t understand why you say 
it has dynamic typing - there is some limited dynamism in parts, but I don’t 
think it affects what we’re talking about. Dynamic typing and polymorphism 
aren’t the same.

 I just don't believe that method overloading would suddenly make
 everyone write poor programs.

Maybe not, but all the facilities needed to make good programs are already 
there. Overloading would only really be useful for writing bad programs, 
because all the good things it enables are already supported by PHP.

 It brings cleaner declarations of methods and functions.

Only slightly. A switch() (or better, a pattern match, were we to add that) can 
do the same job and it’s not that much less clean.

 Also, it
 brings the possibility of having operator overloading in user classes
 someday in the future (yes, this can be abused as well, but it also
 has legitimate use cases - like class for representing Money and being
 able to do +, - , / or * operations on them).

Overloading isn’t necessary for operator overloading.

 Is the option of omiting
 type hints and having optional parameters really a good enough
 replacement for method overloading polymorphism for you? Because for
 me, it unfortunately is not. :(

Could you give an example use-case?

 Read the example once more, please - the issue I see with it is that
 bar() requires float, but foo() just number and doesn't convert it to
 the required type. The most unpredictable thing is that it will work
 half of the time and half of the time it will just throw errors.

Well, yes. PHP is dynamically-typed, this can happen, whether you’re using 
strict or weak typing. Your only way to guard against it here is to do proper 
testing. Well, if we added a numeric type hint, your IDE could catch this error 
for you, actually.

Anyway, the same thing can happen for float-int conversions *with* weak 
typing, as we disallow certain conversions (PHP_INT_MIN  $x,  PHP_INT_MAX  
$x, !isfinite($x), isnan($x)).

Also, even though PHP does allow most float-int conversions with weak typing, 
it doesn’t mean they’re a good idea. Silently losing the fractional part is 
probably not what you want.

Thanks.
--
Andrea Faulds
http://ajf.me/





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

RE: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-12 Thread François Laupretre

Hi,

  2- Lack of numeric scalar type
  There're others, but these ones are keys to make them fully usable.
 
 A number (or numeric, or num, or some other name) type hint is something I
 plan to propose in a future, follow-up RFC.

For a set of 'extended' types like 'number', and their matching rules against 
zvals, this may help :

https://wiki.php.net/rfc/dbc#dbc_types_vs_zval_types

Cheers

François


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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-12 Thread Pavel Kouřil

On Thu, Feb 12, 2015 at 1:45 PM, Andrea Faulds a...@ajf.me wrote:
 Hi Pavel,

 C# also doesn’t have dynamic typing. Plus, adding overloading to an existing 
 language is more difficult.


C# does have dynamic typing.

Adding method overloading to an existing language may be more
difficult than creating a new language from ground up, but I'd guess
it's definitely not impossible (I can't say for sure, because I do not
know C and PHP's internals).

 Overloading on scalar types - unpredictable how? Even with weak calls,
 the best candidate could be chosen?

 Still likely to cause chaos. If you can overload based on scalar types, then 
 foobar($a / 2) could call any of *three* different functions.


Sorry, but if you create functions foobar(int $x) and foobar(float $y)
which do totally different things, I'd argue that you brought the
chaos upon yourself. About the third option for called function, I'll
have to admit that I do not know of any other possible signature of a
function that the call could lead to, if we go by choose the best
candidate strategy for resolving.

 Of course, sometimes there will be
 an abmbiguous call, but as long as there would be a way to define
 which call you want, it shouldn't be a problem as well?

 “A way to define which call you want”? Sounds like a hacky workaround to me.


Scratch that, I was thinking about something else while writing this.
Error on an ambiguous call is probably the best way to handle this.

 Poor API - for useland code or in PHP's functions itself? But I don't
 think this should be considered as a real problem, because in userland
 code, developers are able to create a poor API even with the current
 versions of PHP.

 That doesn’t mean we should make it any easier.


I just don't believe that method overloading would suddenly make
everyone write poor programs. Also, they can do the same poor coding
with tons of ifs and elses in one method without typehint and
declaring multiple types in phpDoc (createFrom($a) and @param X|Y|Z in
phpDoc), or they have to create multiple methods which have some
suffix (createFromX, createFromY, createFromZ).

 If someone wants to shoot himself in the foot, he
 will do it in one way or another. And at the same time, polymorphism
 via method overloading can lead to a cleaner APIs, if it's used well.

 I don’t see how. The main things it enables are optional parameters (which we 
 already support) and polymorphism (which we already support). So you’d have 
 to explain what overloading brings to the table beyond those two things.


It brings cleaner declarations of methods and functions. Also, it
brings the possibility of having operator overloading in user classes
someday in the future (yes, this can be abused as well, but it also
has legitimate use cases - like class for representing Money and being
able to do +, - , / or * operations on them). Is the option of omiting
type hints and having optional parameters really a good enough
replacement for method overloading polymorphism for you? Because for
me, it unfortunately is not. :(

 Well, about number type hint. How this would work, in combination
 with strict types?

 function bar(float $f) {
return $f * 1.23;
 }

 function foo(number $x) {
return bar($x);
 }

 foo(1);

 From my understanding, it wouldn’t?

 It would accept an integer or a float, because both subclass number:

 function foobar(): number {
 return 1.0; // okay
 return 1; // okay
 }

 function foo(number $x) {}
 foo(1.0); // okay
 foo(1); // okay

 I don’t see why it “wouldn’t work”.

Read the example once more, please - the issue I see with it is that
bar() requires float, but foo() just number and doesn't convert it to
the required type. The most unpredictable thing is that it will work
half of the time and half of the time it will just throw errors. Sure,
the blame in this case is on all 3 participants - strict typing (and
no int - float conversion), programmer itself and number typehint
(it just doesn't work well with the strict typing) - but as you said,
should you make writing poor programs easier? Just kidding with the
last sentence :) ... but honestly, I do find method overloading and
implicit conversions from int to float a better way to solve the
usecases for number typehint.

Regards
Pavel Kouril

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hi Pavel,

 On 12 Feb 2015, at 12:39, Pavel Kouřil pajou...@gmail.com wrote:
 
 I don't see any problem with combination of optional parameters with
 method overloading. C# has it and it is pretty useful and works there
 without any bigger issues. Sure, the dynamic typing may be a (small)
 issue, but again, C# does it in an IMHO meaningful way as well and it
 can be used as an inspiration, should this way be chosen.

C# also doesn’t have dynamic typing. Plus, adding overloading to an existing 
language is more difficult.

 Overloading on scalar types - unpredictable how? Even with weak calls,
 the best candidate could be chosen?

Still likely to cause chaos. If you can overload based on scalar types, then 
foobar($a / 2) could call any of *three* different functions.

 Of course, sometimes there will be
 an abmbiguous call, but as long as there would be a way to define
 which call you want, it shouldn't be a problem as well?

“A way to define which call you want”? Sounds like a hacky workaround to me.

 Poor API - for useland code or in PHP's functions itself? But I don't
 think this should be considered as a real problem, because in userland
 code, developers are able to create a poor API even with the current
 versions of PHP.

That doesn’t mean we should make it any easier.

 If someone wants to shoot himself in the foot, he
 will do it in one way or another. And at the same time, polymorphism
 via method overloading can lead to a cleaner APIs, if it's used well.

I don’t see how. The main things it enables are optional parameters (which we 
already support) and polymorphism (which we already support). So you’d have to 
explain what overloading brings to the table beyond those two things.

 Well, about number type hint. How this would work, in combination
 with strict types?
 
 function bar(float $f) {
return $f * 1.23;
 }
 
 function foo(number $x) {
return bar($x);
 }
 
 foo(1);
 
 From my understanding, it wouldn’t?

It would accept an integer or a float, because both subclass number:

function foobar(): number {
return 1.0; // okay
return 1; // okay
}

function foo(number $x) {}
foo(1.0); // okay
foo(1); // okay

I don’t see why it “wouldn’t work”.
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-12 Thread Pavel Kouřil

On Thu, Feb 12, 2015 at 12:44 PM, Andrea Faulds a...@ajf.me wrote:

 PHP already has polymorphism through its dynamic typing. I don’t see method 
 overloading happening any time soon. We have optional parameters and dynamic 
 typing, which all but eliminate the main needs for overloading. We’re a 
 weakly-typed language, so overloading on scalar types might cause 
 unpredictable behaviour (with strict types you’d get an error sometimes, and 
 that’s fine - but calling an entirely different function? Now that’s 
 different.) There’s also the question of how, or if at all, method 
 overloading could interact with our optional parameters and dynamic typing. 
 Finally, overloading can lead to really poor API design: it’s not that 
 uncommon in some languages to see 20 different function definitions with 
 overlapping and non-comprehensive subsets of a method’s behaviour, that are 
 distinguished only by parameter types. It’s one of my least favourite 
 Java/C#/C++ features for that reason.

 In response to saying numbers are not a type: well, they are more of an 
 abstract type which integer and float subclass. We already have internal 
 facilities for converting to and from “numbers” alongside integers and 
 floats, I don’t see why we can’t expose this to users.


Hello,

I don't see any problem with combination of optional parameters with
method overloading. C# has it and it is pretty useful and works there
without any bigger issues. Sure, the dynamic typing may be a (small)
issue, but again, C# does it in an IMHO meaningful way as well and it
can be used as an inspiration, should this way be chosen.

Overloading on scalar types - unpredictable how? Even with weak calls,
the best candidate could be chosen? Of course, sometimes there will be
an abmbiguous call, but as long as there would be a way to define
which call you want, it shouldn't be a problem as well?

Poor API - for useland code or in PHP's functions itself? But I don't
think this should be considered as a real problem, because in userland
code, developers are able to create a poor API even with the current
versions of PHP. If someone wants to shoot himself in the foot, he
will do it in one way or another. And at the same time, polymorphism
via method overloading can lead to a cleaner APIs, if it's used well.

Well, about number type hint. How this would work, in combination
with strict types?

function bar(float $f) {
return $f * 1.23;
}

function foo(number $x) {
return bar($x);
}

foo(1);

From my understanding, it wouldn't?

Regards
Pavel Kouril

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-12 Thread Nikita Nefedov

Hi,

2015-02-12 18:31 GMT+04:00 Andrea Faulds a...@ajf.me:

 Hi Pavel,

  On 12 Feb 2015, at 13:48, Pavel Kouřil pajou...@gmail.com wrote:
 
  C# does have dynamic typing.

 No it doesn’t, it’s a statically-typed language. I don’t understand why
 you say it has dynamic typing - there is some limited dynamism in parts,
 but I don’t think it affects what we’re talking about. Dynamic typing and
 polymorphism aren’t the same.


 C# actually supports dynamic typing with a dynamic keyword [1]. But it
really doesn't mean that having method overloading in a dynamic language is
a good idea... C#, although it has a full ability to support dynamic
typing, is not usually used in this fashion. To understand why it's not the
best idea to use dynamic types with overloading you can just google C#
dynamic type with overloading site:stackoverflow.com.

Another great deal in this question is performance, I think this subject
was brought up a plenty of times in this ML and it was pointed out a couple
of times that overloading even if doable at some point, would harm
performance of method calls, which are already one of the slowest (if not
the slowest) OPs in the engine. Languages like C# are usually able to
resolve method references at compile time (unless virtual methods are used,
even then it's only a matter of choosing right method from hierarchy not
from all the overloaded variants).

[1] https://msdn.microsoft.com/en-us/library/dd264736.aspx

AW: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-12 Thread Robert Stoll

Hi François,

 -Ursprüngliche Nachricht-
 Von: François Laupretre [mailto:franc...@tekwire.net]
 Gesendet: Donnerstag, 12. Februar 2015 18:01
 An: 'Robert Stoll'; 'Nikita Nefedov'; 'Andrea Faulds'
 Cc: 'Pavel Kouřil'; 'PHP Internals'
 Betreff: RE: [PHP-DEV] [VOTE] Scalar Type Hints
 
 Hi Robert,
 
  De : Robert Stoll [mailto:p...@tutteli.ch]
 
  There are several programming languages which do support dynamic
  typing and method overloading somehow (Clojure, Erlang, Prolog, Cecil
  and certainly more).  Most of them use a multi-method approach and I
  think if PHP would introduce function/method overloading, then such an
  approach would be appropriate. Right now, I need to implement the
  dynamic dispatching quasi myself which might be more verbose but is
  also more cumbersome (and uglier IMO). Consider the following (fictional 
  example):
 
 We all agree on the interest of polymorphism on object classes, even if your 
 example could be solved with specialized
 logger classes, but the question was about polymorphism on different scalar 
 types, which is much more problematic in PHP,
 even using strict scalar typing.
 
 Cheers
 
 François

OK, maybe I went a little bit off topic due to the booted discussion about 
method overloading which did not cover all aspects IMO.  So back to scalar type 
hints:
I do not really see how num would be a problem or polymorphism in general. I am 
not really aware of memory management of PHP but I guess it is not optimised 
for fixed-sized integers or is it?
If not, then it does not really matter whether a parameter holds an int, a 
float or a BigInt, allocation is dynamic anyway I suppose. Or what problems do 
you see here?

Maybe you are referring to Pavel's example:

 the issue I see with it is that bar() requires float, but foo() just number 
 and doesn't convert it to the required type. The most unpredictable thing is 
 that it will work half of the time and half of the time it will just throw 
 errors

The same applies for the following code

class Foo{}
class Bar{}

function foo(Foo foo){
  bar($foo);
}
function bar(Bar bar){
   //..
}

and we still agree upon that polymorphism is the right way to go since it 
allows more expressive code with a certain safety. If you want full 
flexibility, then rely on dynamic typing only and if you want some safety then 
use type hints.  I do not see a special case here - polymorphism for scalar 
types is nothing new


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

AW: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-12 Thread Robert Stoll

 -Ursprüngliche Nachricht-
 Von: Nikita Nefedov [mailto:inefe...@gmail.com]
 Gesendet: Donnerstag, 12. Februar 2015 15:54
 An: Andrea Faulds
 Cc: Pavel Kouřil; PHP Internals
 Betreff: Re: [PHP-DEV] [VOTE] Scalar Type Hints
 
 Hi,
 
 2015-02-12 18:31 GMT+04:00 Andrea Faulds a...@ajf.me:
 
  Hi Pavel,
 
   On 12 Feb 2015, at 13:48, Pavel Kouřil pajou...@gmail.com wrote:
  
   C# does have dynamic typing.
 
  No it doesn’t, it’s a statically-typed language. I don’t understand
  why you say it has dynamic typing - there is some limited dynamism in
  parts, but I don’t think it affects what we’re talking about. Dynamic
  typing and polymorphism aren’t the same.
 
 
  C# actually supports dynamic typing with a dynamic keyword [1]. But it 
 really doesn't mean that having method
 overloading in a dynamic language is a good idea... C#, although it has a 
 full ability to support dynamic typing, is not usually
 used in this fashion. To understand why it's not the best idea to use dynamic 
 types with overloading you can just google
 C# dynamic type with overloading site:stackoverflow.com.
 
 Another great deal in this question is performance, I think this subject was 
 brought up a plenty of times in this ML and it
 was pointed out a couple of times that overloading even if doable at some 
 point, would harm performance of method calls,
 which are already one of the slowest (if not the slowest) OPs in the engine. 
 Languages like C# are usually able to resolve
 method references at compile time (unless virtual methods are used, even then 
 it's only a matter of choosing right method
 from hierarchy not from all the overloaded variants).
 
 [1] https://msdn.microsoft.com/en-us/library/dd264736.aspx


There are several programming languages which do support dynamic typing and 
method overloading somehow (Clojure, Erlang, Prolog, Cecil and certainly more). 
 Most of them use a multi-method approach and I think if PHP would introduce 
function/method overloading, then such an approach would be appropriate. Right 
now, I need to implement the dynamic dispatching quasi myself which might be 
more verbose but is also more cumbersome (and uglier IMO). Consider the 
following (fictional example):

I want to write a Logger-Service which provides one public method log which 
writes all kind of objects to a log. The corresponding classes do not all 
belong to my code base, are part of third party libraries respectively, so I am 
not able to introduce some interface which all classes implement. The strategy 
pattern is certainly a good idea for this problem but nevertheless, somewhere I 
need to have the distinction based on many if/else with instanceof (latest in 
the LoggerStrategyFactory) -- off topic, if someone has a better design 
approach to handle this problem, then let me know it in a private message, 
would be interesting as well ;)

class Logger{
  public function log($x){
if($x instanceof Foo){
   logFoo($x);
}else if($x instanceof Bar){
  logBar($x);
}
//...
}else{
   throw new Exception(type .gettype($x). not supported);
}
  }
  private function logFoo(Foo $f){
//..
  }
  private function logBar(Bar $b){
   //..
  }
  //...
}

With method overloading I could write the following, removing the hassle to 
write the dynamic dispatch myself:

class Logger{
  public log(){
$this-_log($x);
  }
  private function _log(Foo $f){
//..
  }
  private function _log(Bar $b){
   //..
  }
  //...
  private function _log($x){
throw new Exception(type .gettype($x). not supported);
  }
}

Which is cleaner IMO.

Cheers,
Robert



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

AW: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-12 Thread Robert Stoll

 -Ursprüngliche Nachricht-
 Von: Andrea Faulds [mailto:a...@ajf.me]
 Gesendet: Donnerstag, 12. Februar 2015 17:50
 An: Robert Stoll
 Cc: Nikita Nefedov; Pavel Kouřil; PHP Internals
 Betreff: Re: [PHP-DEV] [VOTE] Scalar Type Hints
 
 Hey Robert,
 
  On 12 Feb 2015, at 16:15, Robert Stoll p...@tutteli.ch wrote:
 
  There are several programming languages which do support dynamic typing and 
  method overloading somehow (Clojure,
 Erlang, Prolog, Cecil and certainly more).  Most of them use a multi-method 
 approach and I think if PHP would introduce
 function/method overloading, then such an approach would be appropriate.
 
 Interesting, I should maybe look into those. I’m not sure if all of those are 
 really… “dynamic” as such. Are you sure the
 overloading you’re referring to there isn’t pattern-matching?
 
  Right now, I need to implement the dynamic dispatching quasi myself which 
  might be more verbose but is also more
 cumbersome (and uglier IMO). Consider the following (fictional example):
 
  I want to write a Logger-Service which provides one public method
  log which writes all kind of objects to a log. The corresponding
  classes do not all belong to my code base, are part of third party
  libraries respectively, so I am not able to introduce some interface
  which all classes implement. The strategy pattern is certainly a good
  idea for this problem but nevertheless, somewhere I need to have the
  distinction based on many if/else with instanceof (latest in the
  LoggerStrategyFactory) -- off topic, if someone has a better design
  approach to handle this problem, then let me know it in a private
  message, would be interesting as well ;)
 
  class Logger{
   public function log($x){
 if($x instanceof Foo){
logFoo($x);
 }else if($x instanceof Bar){
   logBar($x);
 }
 //...
 }else{
throw new Exception(type .gettype($x). not supported);
 }
   }
   private function logFoo(Foo $f){
 //..
   }
   private function logBar(Bar $b){
//..
   }
   //...
  }
 
  With method overloading I could write the following, removing the hassle to 
  write the dynamic dispatch myself:
 
  class Logger{
   public log(){
 $this-_log($x);
   }
   private function _log(Foo $f){
 //..
   }
   private function _log(Bar $b){
//..
   }
   //...
   private function _log($x){
 throw new Exception(type .gettype($x). not supported);  } }
 
  Which is cleaner IMO.
 
 We could also add some sort of pattern-matching syntax which could do the 
 same thing, but would have usefulness
 beyond merely dispatching to multiple methods.
 
 --

Sure, IMO that is just another way to support overloading, or rather the other 
way round, overloading is in some cases just another form of supporting pattern 
matching based only on types (as you said, pattern matching is way more 
powerful than just distinguishing types). In this sense, pattern matching would 
be even more useful and would surely have my support. Yet, there are cases 
where pattern matching is rather ugly as well. Let's consider the code above 
again and let us assume we have more than 10 different types which we want to 
log. Having all the logic in one pattern match block is rather ugly and does 
pretty much violate the single responsibility principle. In such a case 
overloading makes more sense and is cleaner.


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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hey Robert,

 On 12 Feb 2015, at 16:15, Robert Stoll p...@tutteli.ch wrote:
 
 There are several programming languages which do support dynamic typing and 
 method overloading somehow (Clojure, Erlang, Prolog, Cecil and certainly 
 more).  Most of them use a multi-method approach and I think if PHP would 
 introduce function/method overloading, then such an approach would be 
 appropriate.

Interesting, I should maybe look into those. I’m not sure if all of those are 
really… “dynamic” as such. Are you sure the overloading you’re referring to 
there isn’t pattern-matching?

 Right now, I need to implement the dynamic dispatching quasi myself which 
 might be more verbose but is also more cumbersome (and uglier IMO). Consider 
 the following (fictional example):
 
 I want to write a Logger-Service which provides one public method log which 
 writes all kind of objects to a log. The corresponding classes do not all 
 belong to my code base, are part of third party libraries respectively, so I 
 am not able to introduce some interface which all classes implement. The 
 strategy pattern is certainly a good idea for this problem but nevertheless, 
 somewhere I need to have the distinction based on many if/else with 
 instanceof (latest in the LoggerStrategyFactory) -- off topic, if someone has 
 a better design approach to handle this problem, then let me know it in a 
 private message, would be interesting as well ;)
 
 class Logger{
  public function log($x){
if($x instanceof Foo){
   logFoo($x);
}else if($x instanceof Bar){
  logBar($x);
}
//...
}else{
   throw new Exception(type .gettype($x). not supported);
}
  }
  private function logFoo(Foo $f){
//..
  }
  private function logBar(Bar $b){
   //..
  }
  //...
 }
 
 With method overloading I could write the following, removing the hassle to 
 write the dynamic dispatch myself:
 
 class Logger{
  public log(){
$this-_log($x);
  }
  private function _log(Foo $f){
//..
  }
  private function _log(Bar $b){
   //..
  }
  //...
  private function _log($x){
throw new Exception(type .gettype($x). not supported);
  }
 }
 
 Which is cleaner IMO.

We could also add some sort of pattern-matching syntax which could do the same 
thing, but would have usefulness beyond merely dispatching to multiple methods.

--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hi Pavel, 

 On 11 Feb 2015, at 07:41, Pavel Kouřil pajou...@gmail.com wrote:
 
 Also, I realized one thing why I think the strict version is a bad
 idea for PHP (in the state PHP is now - in an ideal world I would love
 to have nothing but strongly typed PHP, but that's offtopic) - PHP has
 many functions that return multiple types, so you cannot do foo(bar())
 if bar() has multiple return types. :(

You can’t do it with weak types either. Functions with multiple return type 
usually do so in order to use one type for success, and another return type on 
failure. In weak typing mode, PHP would just mangle the error value (like 
FALSE).

--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hi Rasmus,

 On 11 Feb 2015, at 06:36, Rasmus Lerdorf ras...@lerdorf.com wrote:
 
  And in Drupal8 *without turning on strict*:
 
  use Drupal\Component\Utility\String;
 
  it dies with: Fatal error: string cannot be used as a class name in
 /var/www/drupal/core/includes/bootstrap.inc on line 11
 
  That String class is everywhere in Drupal. They are going to have a
  fun time with that. See
 https://gist.githubusercontent.com/anonymous/d9252deeeb2aae1a5af5/raw/053155130d22551b1404d0a9b94e27424544b6d1/gistfile1

Such classes will unfortunately have to be renamed. However, this is only true 
if the code needs to run on PHP 7. For PHP 5 codebase compatibility, Drupal can 
do this:

class StringHelper {
…
}
if (version_compare(phpversion(), “7.0)  0) {
class_alias(“Drupal\\Component\\Utility\\StringHelper”, 
“Drupal\\Component\\Utility\\String”);
}

This way, only code made “PHP 7-ready will have to replace its references to 
String with, say, StringHelper. Drupal can work on both PHP 5 and PHP 7, but 
codebases using it can migrate at their own pace.

--
Andrea Faulds
http://ajf.me/





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

RE: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-11 Thread Zeev Suraski

 -Original Message-
 From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
 Sent: Wednesday, February 11, 2015 8:37 AM
 To: Xinchen Hui; Andrea Faulds
 Cc: PHP Internals
 Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints

 On 02/10/2015 07:57 PM, Xinchen Hui wrote:
  am I wrong?!
  seems I am wrong with this, it's a false alarm...  it can restore
 automatically.

 Yeah, declare() doesn't span files so that isn't a problem.

 My worry is still the lack of type coercion for internal calls.

There's also some pretty interesting analysis on this proposal - based on
some real world experimentation - from Benjamin Eberlei - bit.ly/1vl0UED

If you've voted on this RFC or intend to vote - please spend the few minutes
to read through his blog post.  It does a good job at actually illustrating
what life would look like if this rubber ends up meeting the road.

Zeev

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-11 Thread Rowan Collins

On 11 February 2015 06:36:52 GMT, Rasmus Lerdorf ras...@lerdorf.com wrote:
  And in Drupal8 *without turning on strict*:

  use Drupal\Component\Utility\String;

 it dies with: Fatal error: string cannot be used as a class name in
/var/www/drupal/core/includes/bootstrap.inc on line 11

  That String class is everywhere in Drupal. They are going to have a
  fun time with that. See
https://gist.githubusercontent.com/anonymous/d9252deeeb2aae1a5af5/raw/053155130d22551b1404d0a9b94e27424544b6d1/gistfile1

That could potentially be avoided if scalar types were reserved as some kind of 
pseudo-class rather than just keywords, because then they would follow 
namespace resolution rules. Theoretically, you could still have a class 
Drupal\Component\Utility\String, and \string would be available as a scalar 
typehint while you were in that namespace.

I'm guessing it's not as simple as that, because the compiler needs to 
distinguish between scalar and classname typehints, but doesn't know what 
classes exist.

In which case, perhaps string as a typehint could always mean \string, and 
if you want to typehint the class you should always use foo\string? Or you 
could ban string as a typehint, and require people to type \string. Either 
seems a little bit magic, though.

Theoretically, I guess they ought to be php\string etc, which would 
accomplish the goal but make them rather unwieldy. It might be worth 
considering, though, given we know the situation's not just hypothetical.

Regards,
-- 
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

 On 11 Feb 2015, at 21:30, Zeev Suraski z...@zend.com wrote:

 -Original Message-
 From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
 Sent: Wednesday, February 11, 2015 8:37 AM
 To: Xinchen Hui; Andrea Faulds
 Cc: PHP Internals
 Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints

 On 02/10/2015 07:57 PM, Xinchen Hui wrote:
 am I wrong?!
 seems I am wrong with this, it's a false alarm...  it can restore
 automatically.

 Yeah, declare() doesn't span files so that isn't a problem.

 My worry is still the lack of type coercion for internal calls.

 There's also some pretty interesting analysis on this proposal - based on
 some real world experimentation - from Benjamin Eberlei - bit.ly/1vl0UED

I disagree with some aspects of the blogpost:

 enabling strict mode completly defeats the purpose, because now we are forced 
 to convert manually, reimplementing weak type hinting in our own code

This isn’t true at all. The key difference between explicit conversions and 
implicit conversions is that they’re, well, *explicit*. You can see them, they 
are blatantly obvious, if you use grep you can find them. Implicit conversions, 
while they can sometimes be great, happen silently and automatically - if they 
screw up, it can be hard to track down where the conversion is taking place. 
With explicit conversions, you’re converting once and you know you’ve 
converted. With implicit conversions, you have no idea where and how often 
values are being converted.

 We write code with casts already, the scalar type hints patch is not 
 necessary for that! Only a superficial level of additional safety is gained, 
 one additional check of something we already know is true!

Yet in the previous part he was explaining how existing code doesn’t use casts 
and would need them added… so therefore, this thing *isn’t* already known to be 
true, and the blogpost is self-contradictory.

 strict mode is useless for library developers, because I always have to 
 assume weak mode anyways.

I don’t really understand at all… either he doesn’t understand the proposal 
(which guarantees you get the types you ask for), or it’s a reference to the 
claim from the previous paragraph, which I’ve already responded to.

 In a well designed application or library, the developer can already trust 
 the types of his variables today, 95% of the time, without even having type 
 hints, using carefully designed abstractions (example Symfony Forms and 
 Doctrine ORM): No substantial win for her from having strict type hints.

Yet he was previously explaining how, actually, data coming in from web 
requests isn’t the correct types.

 In a badly designed application, the developer is uncertain about the types 
 of variables. Using strict mode in this scenario she needs to start casting 
 everywhere just to be sure.

In an application using strict mode everywhere with scalar type hints 
everywhere, you can’t possibly be uncertain about the types of variables.

… there’s a lot more in that blog post I could disagree with, but I won’t 
bother. Benjamin has his reasons for not liking strict mode. That’s fine. But 
if PHP adds strict mode, it has zero effect on him.

 If you've voted on this RFC or intend to vote - please spend the few minutes
 to read through his blog post.  It does a good job at actually illustrating
 what life would look like if this rubber ends up meeting the road.

Anthony Ferrara also had his own analysis which showed some of the problems 
with weak type hinting, and where strict types can be beneficial: 
http://blog.ircmaxell.com/2015/02/scalar-types-and-php.html

I would suggest people read that blog post before voting, as well. It points 
out some real-world examples of where weak typing in PHP can be insufficient 
(div), or even downright dangerous (curlopt).

--
Andrea Faulds
http://ajf.me/

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

RE: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-11 Thread Zeev Suraski

I said numerous times that I think that v0.1 of Andrea’s RFC was right on
the mark.  I’d vote in its favor in a heartbeat.  It gives the exact same
value from an API author’s point of view.  It gives the exact same value in
terms of potential performance improvements/JITting/compilation insight.
But unlike the current RFC, v0.1 doesn’t introduce an IMHO alien concept
into a language that considered dynamic typing to be a core principle since
its birth.



Zeev



*From:* guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com]
*Sent:* Thursday, February 12, 2015 12:46 AM
*To:* Andrea Faulds
*Cc:* Zeev Suraski; Rasmus Lerdorf; PHP Internals
*Subject:* Re: [PHP-DEV] [VOTE] Scalar Type Hints



Hi all,



@Zeev and @Rasmus:

Seriously, you both mentioned that consider the idea of scalar type hint,
but I've never seen which idea would you consider.

Andrea built a very flexible way to operate and even though I don't fully
agree either, it's the best so far. This approach does have headaches, but
would you ever consider a strict or weak only approach?

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-11 Thread Lester Caine

On 11/02/15 21:46, Andrea Faulds wrote:
 Anthony Ferrara also had his own analysis which showed some of the problems 
 with weak type hinting, and where strict types can be beneficial: 
 http://blog.ircmaxell.com/2015/02/scalar-types-and-php.html

What is the point of using a 'Better static analyzer' when the bulk of
the material being worked with simply can't be processed 'statically'?
The only result of this passing that I can see is that PHP will start to
develop two completely different code bases. Anthony closes by saying
that is EXACTLY what he will do ...

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Fwd: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-11 Thread Benjamin Eberlei

Forarding again, was rejected by the list because of spammy links :(

-- Forwarded message --
From: Benjamin Eberlei kont...@beberlei.de
Date: Thu, Feb 12, 2015 at 12:59 AM
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
To: Andrea Faulds a...@ajf.me
Cc: Zeev Suraski z...@zend.com, Rasmus Lerdorf ras...@lerdorf.com, PHP
Internals internals@lists.php.net

On Wed, Feb 11, 2015 at 10:46 PM, Andrea Faulds a...@ajf.me wrote:

  On 11 Feb 2015, at 21:30, Zeev Suraski z...@zend.com wrote:

  -Original Message-
  From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
  Sent: Wednesday, February 11, 2015 8:37 AM
  To: Xinchen Hui; Andrea Faulds
  Cc: PHP Internals
  Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints

  On 02/10/2015 07:57 PM, Xinchen Hui wrote:
  am I wrong?!
  seems I am wrong with this, it's a false alarm...  it can restore
  automatically.

  Yeah, declare() doesn't span files so that isn't a problem.

  My worry is still the lack of type coercion for internal calls.

  There's also some pretty interesting analysis on this proposal - based on
  some real world experimentation - from Benjamin Eberlei

 I disagree with some aspects of the blogpost:

  enabling strict mode completly defeats the purpose, because now we are
 forced to convert manually, reimplementing weak type hinting in our own code

 This isn’t true at all. The key difference between explicit conversions
 and implicit conversions is that they’re, well, *explicit*. You can see
 them, they are blatantly obvious, if you use grep you can find them.
 Implicit conversions, while they can sometimes be great, happen silently
 and automatically - if they screw up, it can be hard to track down where
 the conversion is taking place. With explicit conversions, you’re
 converting once and you know you’ve converted. With implicit conversions,
 you have no idea where and how often values are being converted.

I agree with the benefits of strict typing and how they are explicit. I
even like programming in strict languages a lot.

But the default way to achieve this is in PHP is to add casts, and they
are done with the weak rules:
strict_func((int)$string); avoids the purpose of strict typing. And that
will probably be the most used way to get strict type compatibility.
Yes, i am probably using it wrong here, but features are not always used
the right way, most of the time they are not.

It got mentoined to me several times that a fix would actually be to have
$request-getInteger('status'); - i will add that to the post later. This
will actually improve the code, but as i mentoined in my post, someone with
a good abstraction for type juggling is already there today.

  We write code with casts already, the scalar type hints patch is not
 necessary for that! Only a superficial level of additional safety is
 gained, one additional check of something we already know is true!

 Yet in the previous part he was explaining how existing code doesn’t use
 casts and would need them added… so therefore, this thing *isn’t* already
 known to be true, and the blogpost is self-contradictory.

You got me there, but the code i showed doesnt actually need strict or
weak types. I use casting in PHP liberaly, as probably many others as well.
If i think I need it, I use it.

  strict mode is useless for library developers, because I always have to
 assume weak mode anyways.

 I don’t really understand at all… either he doesn’t understand the
 proposal (which guarantees you get the types you ask for), or it’s a
 reference to the claim from the previous paragraph, which I’ve already
 responded to.

I understand the proposal. As a library author i would use type hints to
help my users make the right input values, recieve the right return values.
But except when I have highly critical code that requires the right types
at all steps, but most of the time inside my library weak type hints would
a.) not step me in the way so much b.) still work out correctly all the
time.

  In a well designed application or library, the developer can already
 trust the types of his variables today, 95% of the time, without even
 having type hints, using carefully designed abstractions (example Symfony
 Forms and Doctrine ORM): No substantial win for her from having strict type
 hints.

 Yet he was previously explaining how, actually, data coming in from web
 requests isn’t the correct types.

Well that example didn't show Symfony Forms nor Doctrine. I could show them
in the blog post, but since they cast all the request + db already, there
wouldn't be much to show. As the blog post says, this kind of code already
provides a lot of trust even without any kind of type hints.

  In a badly designed application, the developer is uncertain about the
 types of variables. Using strict mode in this scenario she needs to start
 casting everywhere just to be sure.

 In an application using strict mode everywhere with scalar type hints
 everywhere, you can’t possibly

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-11 Thread Rowan Collins

On 11 February 2015 22:41:21 GMT, Lester Caine les...@lsces.co.uk wrote:
On 11/02/15 21:46, Andrea Faulds wrote:
 Anthony Ferrara also had his own analysis which showed some of the
problems with weak type hinting, and where strict types can be
beneficial: http://blog.ircmaxell.com/2015/02/scalar-types-and-php.html

What is the point of using a 'Better static analyzer' when the bulk of
the material being worked with simply can't be processed 'statically'?
The only result of this passing that I can see is that PHP will start
to
develop two completely different code bases. Anthony closes by saying
that is EXACTLY what he will do ...

No, he closes by saying he will use the feature differently in different parts 
of one code base. Indeed, he makes a specific point about the advantage of 
having a weakly typed file and a strictly typed file working together.



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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hey Guilherme,

 On 11 Feb 2015, at 22:46, guilhermebla...@gmail.com wrote:
 
 @Andrea: I spent around 2-3 hours speaking with Anthony and the other half 
 talking to Jordi (Composer, Symfony).
 I still think a few things are required to be fully usable.
 1- Exceptions RFC (outside of your scope, but making the code under strict 
 type impossible to recover in a library)

Yeah, I agree that this is quite important. This could actually be fixed 
without exceptions (make type hint error skip the function call?), but they’re 
a nicer way to do it (possibly simpler within the engine?).

 2- Lack of numeric scalar type
 There're others, but these ones are keys to make them fully usable.

A number (or numeric, or num, or some other name) type hint is something I plan 
to propose in a future, follow-up RFC.

Thanks.
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-11 Thread Sebastian B.-Hagensen

Hi,

2015-02-12 0:08 GMT+01:00 Zeev Suraski z...@zend.com:
  It gives the exact same
 value from an API author’s point of view.

But not from an api-consumers point of view. Without either
introducing a new set of casting/conversion rules or changing existing
behavior  (**exclusively**) 'weak' typehints may be perceived as
seriously crippled. Maybe up to a point where the addition of them
wouldn't be justified.

 But unlike the current RFC, v0.1 doesn’t introduce an IMHO alien concept
 into a language that considered dynamic typing to be a core principle since
 its birth.

It's not. PHP was always open to enforce strict typing in user created
functions. If types didn't matter the way they do the current
distinguishing between int/float or respectively
array/stdClass/Objects shouldn't exist. But thankfully they are
distinctive. The proposal offers a way to conditionally harmonize
different usage patterns. (Across code bases and with internal
functions)

Having the ability to conditionally tighten rules in self written code
but falling back to loose (in many cases good, in other cases
disastrous) behavior is what modern PHP defines.

To much new code already enforces strict types. Using if(!is_int)
throw new WrongArgumentTypeException() or similar.

The proposed RFC could unify such codebases. Having typehints in the
proposed form would allow the api creator to drop most additional type
checks as the method always receives what was asked for and shifts
responsibility to the user. The way how an API is used would be
determined by the user, allowing them to continue to use the weak
behavior if they want but also offer them to enforce the rules that
otherwise the api creator might force on everyone.

Why don't you want to allow people to use (formerly your) language in
the way they see fit as you have already given them the broader
framework do to so. Having optional strict hints together with the
performance improvements and the maturing php ecosystem
(composer/fig/co. + enterprise-targeting frameworks) may even attract
new users to php that don't want or require the mental burden or the
ecosystem given by other languages(java,c#) but don't want to miss the
additional safety and feeling of strict types.

The other options (globally changing zpp rules and the behavior of
implicit casts) sharing most of the advantages implied in the current
proposal was already proposed as RFC and talked down as the BC break
was considered to big. The concept behind the current RFC (not so much
the syntax) is the only way to satisfy both camps without alienating a
large part of the community. I'd even argue that weak hints alone
wouldn't be able to reach a 2/3 majority as strict supporters (Over
1/3rd of what I've seen on this list) would need be afraid that their
preference would never reach the required majority once weak hints are
in.

It's this proposal, semi-strict hints or changed conversion rules (The
alternatives would either introduce yet another set of unconditional
rules or require a considerable BC break as noted above). Everything
else will either not reach the required majority or will alienate
potentially large parts of the user land community (Which aren't
necessarily known to the oss community, zend or similar).


Thanks

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-11 Thread Pavel Kouřil

On Thu, Feb 12, 2015 at 1:13 AM, Andrea Faulds a...@ajf.me wrote:

 A number (or numeric, or num, or some other name) type hint is something I 
 plan to propose in a future, follow-up RFC.


Hello,

wouldn't polymorphism (via method overloading) solve the use cases and
be much more useful in the long run than introducing a something
that's not a type into type hints?

Regards
Pavel Kouril

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-11 Thread Nikita Nefedov

On 11 Feb 2015 09:38, Rasmus Lerdorf ras...@lerdorf.com wrote:

 On 02/10/2015 07:57 PM, Xinchen Hui wrote:
  am I wrong?!
  seems I am wrong with this, it's a false alarm...  it can restore
automatically.

 Yeah, declare() doesn't span files so that isn't a problem.

 My worry is still the lack of type coercion for internal calls. I tested
 it on some apps and it will take quite a bit of tedious and rather
 useless effort to fix these to run in strict mode. Some examples of
 common things that are fatal errors in strict mode:

   ini_set('precision', 14);

   ini_set('display_errors', 1);

   ini_set('display_errors', true);

   ok, not common, but tan(4/2) fatal, tan(5/2) no error

   Wordpress has this function, spot the error:

   function add_magic_quotes( $array ) {
 foreach ( (array) $array as $k = $v ) {
 if ( is_array( $v ) ) {
 $array[$k] = add_magic_quotes( $v );
 } else {
 $array[$k] = addslashes( $v );
 }
 }
 return $array;
   }

   $v may not always be a string (it died with a float for me), so the
   fix is to cast:

 $array[$k] = addslashes( (string)$v );

   Also from Wordpress:

   $formatted = number_format( $number, absint( $decimals ),
 $wp_locale-number_format['decimal_point'],
 $wp_locale-number_format['thousands_sep'] );

   Here number_format() is expecting a float but $number is a string. So
   again, the only real fix is to cast.

   And in Drupal8 *without turning on strict*:

   use Drupal\Component\Utility\String;

   it dies with: Fatal error: string cannot be used as a class name in
 /var/www/drupal/core/includes/bootstrap.inc on line 11

   That String class is everywhere in Drupal. They are going to have a
   fun time with that. See

https://gist.githubusercontent.com/anonymous/d9252deeeb2aae1a5af5/raw/053155130d22551b1404d0a9b94e27424544b6d1/gistfile1

   From Geeklog:

   if (strtolower($topic) != strtolower($archivetid)) {
 $sql .=  AND ta.tid != '{$archivetid}' ;
   }

   $topic can be null there. Looking at the logic, not really a bug,
   just a natural reliance on null being coerced to 

   Also from Geeklog:

 if( empty( $date )) {
 // Date is empty, get current date/time
 $stamp = time();
 } else if( is_numeric( $date )) {
 // This is a timestamp
 $stamp = $date;
 } else {
 // This is a string representation of a date/time
 $stamp = strtotime( $date );
 }
 // Format the date
 $date = strftime( $dateformat, $stamp );

 strftime() expects an integer for the timestamp there, but as the
 above logic shows, they are expecting a numeric string to be fine.
 No bug, just another forced cast.

 And another number_format() instance where arg1 is not necessarily
 a float. Obviously not a bug, so we have to cast again:

 return number_format( $number, $dc, $ds, $ts );

 In Opencart:

 $this-image = imagecreatetruecolor($width, $height);
 imagecreatetruecolor() expects parameter 1 to be integer, string
 given in /var/www/opencart/system/library/image.php on line 89

 You could argue this is a bug, I guess, but the width and height are
 coming from a database and are integers in the db, but since the db
 returns strings. Another cast...

 I was genuinely hoping to find some bugs with this exercise. I suppose
 it is because I did it on mature projects and at this stage those sorts
 of bugs have already been fixed. But I still fear that people are going
 to want to be enable strictness everywhere and then they will quickly
 learn that they better cast stuff to be safe which makes the whole thing
 rather pointless. And I feel pretty sorry for the Drupal folks. That
 list of 1000+ instances of their String class is going to suck to fix.

 -Rasmus


Hi,

I believe all these projects wouldn't even want to enable strict types due
to the nature of their codebase and they probably don't need to, for sure
this feature is not for them...
What about Drupal, if they don't use dynamic instantiation for string
utility class then it can be fixed in most of IDEs out there with their
rename class feature. Plus keywords reservation is a matter of another
vote (the last one in the RFC) that can succeed even if type hints don't
pass.

RE: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-11 Thread Zeev Suraski

 -Original Message-
 From: Sebastian B.-Hagensen [mailto:sbj.ml.r...@gmail.com]
 Sent: Thursday, February 12, 2015 2:11 AM
 To: Zeev Suraski
 Cc: guilhermebla...@gmail.com; Rasmus Lerdorf; PHP Internals
 Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints

 Hi,

 2015-02-12 0:08 GMT+01:00 Zeev Suraski z...@zend.com:
   It gives the exact same
  value from an API author’s point of view.

 But not from an api-consumers point of view.

I didn't claim otherwise.  I am claiming that piece is significantly less
important, and that its negative implications outweigh its positive ones.

 Without either introducing a
 new set of casting/conversion rules or changing existing behavior
 (**exclusively**) 'weak' typehints may be perceived as seriously crippled.
 Maybe up to a point where the addition of them wouldn't be justified.

I argued we should tweak the conversion rules.

  But unlike the current RFC, v0.1 doesn’t introduce an IMHO alien
  concept into a language that considered dynamic typing to be a core
  principle since its birth.

 It's not. PHP was always open to enforce strict typing in user created
 functions.

Being able to do something in custom code - and having language-level syntax
for it are a world a part in terms of condoned language principles.  That's
why proponents of this RFC are so much in its favor - and opponents are so
much against.  This new syntax would mean explosive growth and official
encouragement for developers to place strict type checking throughout their
code.

Zeev

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-10 Thread Xinchen Hui

Hey:

On Wed, Feb 11, 2015 at 11:36 AM, Xinchen Hui larue...@php.net wrote:
 Hey:


 On Fri, Feb 6, 2015 at 4:14 AM, Andrea Faulds a...@ajf.me wrote:
 Good evening,

 At long last, I’m going to put the RFC to a vote. It’s been long enough - I 
 don’t think there needs to be, or will be, much further discussion.

 I’d like to make sure that everyone voting understands the RFC fully. Please 
 read the RFC in full: the details are important. And if  anyone has any 
 questions or uncertainties, please ask them before voting. I am very happy 
 to answer them.

 I would urge everyone who wants type hints to vote for this RFC. It is not a 
 perfect solution, but there can be no perfect solution to this issue. 
 However, I think it is better than most of the alternatives suggested thus 
 far - see the rationale section, and previous discussions. Crucially, this 
 RFC would keep PHP a weakly-typed language, and not force either strict 
 typing, nor weak typing, on anyone who does not want it. It would allow the 
 addition of type hints to existing codebases. It would not create a 
 situation where userland functions are strict yet internal functions are 
 not, because the strict mode affects both. I’ve tested the implementation 
 myself on my own code, and it worked well, providing benefits other 
 proposals would not have given (see my previous post about my experiences).

 Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). 
 In addition to the vote on the main RFC, there is also a vote on the type 
 aliases issue, and a vote to reserve the type names for future RFCs’ sake if 
 this RFC fails.

 The RFC can be found here, and it contains a voting widget: 
 https://wiki.php.net/rfc/scalar_type_hints

 Thank you for your time.

 Actually,  I was surprised by the progress of voting now...

 Seems never have so many users to vote...  and bulk of active core
 developers are vote against on it.

 As a PHP user,  I actually don't care about scalar type hinting much..

 but I am strongly objecting declare thing...

 image of,  one line setting care make a project doesn't work...

 image of,  a larger project, some devers user strict_type, some for
 safe doesn't use..

 then they have to add declare to every files's head...

 it's a nightmare

 I , here, acking you please reconsidering your vote...

?php

   include_one lib/.php // it use strict type

   declare(strict_types=0); //damned , restore it.


   $a = new B; // autoload, target file use strict type,

   declare(strict_types = 0); //damned, restore it.


?

am I wrong?!

thanks

 thanks
 --
 Andrea Faulds
 http://ajf.me/





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




 --
 Xinchen Hui
 @Laruence
 http://www.laruence.com/



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-10 Thread Xinchen Hui

Hey:


On Fri, Feb 6, 2015 at 4:14 AM, Andrea Faulds a...@ajf.me wrote:
 Good evening,

 At long last, I’m going to put the RFC to a vote. It’s been long enough - I 
 don’t think there needs to be, or will be, much further discussion.

 I’d like to make sure that everyone voting understands the RFC fully. Please 
 read the RFC in full: the details are important. And if  anyone has any 
 questions or uncertainties, please ask them before voting. I am very happy to 
 answer them.

 I would urge everyone who wants type hints to vote for this RFC. It is not a 
 perfect solution, but there can be no perfect solution to this issue. 
 However, I think it is better than most of the alternatives suggested thus 
 far - see the rationale section, and previous discussions. Crucially, this 
 RFC would keep PHP a weakly-typed language, and not force either strict 
 typing, nor weak typing, on anyone who does not want it. It would allow the 
 addition of type hints to existing codebases. It would not create a situation 
 where userland functions are strict yet internal functions are not, because 
 the strict mode affects both. I’ve tested the implementation myself on my own 
 code, and it worked well, providing benefits other proposals would not have 
 given (see my previous post about my experiences).

 Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). In 
 addition to the vote on the main RFC, there is also a vote on the type 
 aliases issue, and a vote to reserve the type names for future RFCs’ sake if 
 this RFC fails.

 The RFC can be found here, and it contains a voting widget: 
 https://wiki.php.net/rfc/scalar_type_hints

 Thank you for your time.

Actually,  I was surprised by the progress of voting now...

Seems never have so many users to vote...  and bulk of active core
developers are vote against on it.

As a PHP user,  I actually don't care about scalar type hinting much..

but I am strongly objecting declare thing...

image of,  one line setting care make a project doesn't work...

image of,  a larger project, some devers user strict_type, some for
safe doesn't use..

then they have to add declare to every files's head...

it's a nightmare

I , here, acking you please reconsidering your vote...


thanks
 --
 Andrea Faulds
 http://ajf.me/





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




-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-10 Thread Xinchen Hui

Hey:

On Wed, Feb 11, 2015 at 11:45 AM, Xinchen Hui larue...@php.net wrote:
 Hey:

 On Wed, Feb 11, 2015 at 11:36 AM, Xinchen Hui larue...@php.net wrote:
 Hey:


 On Fri, Feb 6, 2015 at 4:14 AM, Andrea Faulds a...@ajf.me wrote:
 Good evening,

 At long last, I’m going to put the RFC to a vote. It’s been long enough - I 
 don’t think there needs to be, or will be, much further discussion.

 I’d like to make sure that everyone voting understands the RFC fully. 
 Please read the RFC in full: the details are important. And if  anyone has 
 any questions or uncertainties, please ask them before voting. I am very 
 happy to answer them.

 I would urge everyone who wants type hints to vote for this RFC. It is not 
 a perfect solution, but there can be no perfect solution to this issue. 
 However, I think it is better than most of the alternatives suggested thus 
 far - see the rationale section, and previous discussions. Crucially, this 
 RFC would keep PHP a weakly-typed language, and not force either strict 
 typing, nor weak typing, on anyone who does not want it. It would allow the 
 addition of type hints to existing codebases. It would not create a 
 situation where userland functions are strict yet internal functions are 
 not, because the strict mode affects both. I’ve tested the implementation 
 myself on my own code, and it worked well, providing benefits other 
 proposals would not have given (see my previous post about my experiences).

 Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). 
 In addition to the vote on the main RFC, there is also a vote on the type 
 aliases issue, and a vote to reserve the type names for future RFCs’ sake 
 if this RFC fails.

 The RFC can be found here, and it contains a voting widget: 
 https://wiki.php.net/rfc/scalar_type_hints

 Thank you for your time.

 Actually,  I was surprised by the progress of voting now...

 Seems never have so many users to vote...  and bulk of active core
 developers are vote against on it.

 As a PHP user,  I actually don't care about scalar type hinting much..

 but I am strongly objecting declare thing...

 image of,  one line setting care make a project doesn't work...

 image of,  a larger project, some devers user strict_type, some for
 safe doesn't use..

 then they have to add declare to every files's head...

 it's a nightmare

 I , here, acking you please reconsidering your vote...

 ?php

include_one lib/.php // it use strict type

declare(strict_types=0); //damned , restore it.


$a = new B; // autoload, target file use strict type,

declare(strict_types = 0); //damned, restore it.


 ?

 am I wrong?!
seems I am wrong with this, it's a false alarm...  it can restore automatically.

ignore me.. :

thanks

 thanks

 thanks
 --
 Andrea Faulds
 http://ajf.me/





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




 --
 Xinchen Hui
 @Laruence
 http://www.laruence.com/



 --
 Xinchen Hui
 @Laruence
 http://www.laruence.com/



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-10 Thread Matt Ficken

FYI, the patch doesn't cause a performance regression.

I built on and tested with IIS/Windows. Performance remains the same for
Wordpress, Symfony and Joomla. Mediawiki actually increased slightly (5%),
so performance is increase/decrease is not an issue here, the language and
engine are.


If you're interested, see:
http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20150209-master_rcaf5521-scalar_type_hints_2_strict_mode-8436.html


Regards
-M


On Mon, Feb 9, 2015 at 6:43 PM, Pierre Joye pierre@gmail.com wrote:

 On Feb 10, 2015 1:22 AM, Lars Strojny l...@strojny.net wrote:
 
  Hi Matteo,
 
  sorry for the late response.
 
   On 07 Feb 2015, at 12:46, Matteo Beccati p...@beccati.com wrote:
  
   Maybe it's just me, but I didn't quite understand the point you are
 making here. Are you saying that declares are more or less like ini
 settings?
 
  Yes, exactly that. The new declare()-statement will fundamentally change
 how the engine behaves and one will have two learn more or less two flavors
 of PHP. Even worse I am forced to use the PHP flavor the person picked who
 changed the declare() statement last.

 No. You are not.

  cu,
  Lars

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-10 Thread Pierre Joye

On Tue, Feb 10, 2015 at 4:56 PM, Dmitry Stogov dmi...@zend.com wrote:
 If you measure performance impact using CPU performance counters (VTune,
 oprofile, perf) or even better CPU emulator (callgrind) you'll see slight
 degradation. It's also clear that it makes some degradation from code
 review. 1% difference is invisible because measurement mistake is usually
 bigger and also performance may change from build to build because of
 different code layout.

At the application level the impact is not relevant.


 Anyway, this is not a stopper, just an issue that would be great to fix.

Full ack. And I would really love to see  the same kindness for this
RFC and the unsolved issues it may have than the one we had for phpng.

This RFC also remembers how critical it is to have a two phases RFC
for such complex tasks. It is demoralizing and a waste of time to do
things as we do now, for such huge thing.

Cheers,
Pierre

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-10 Thread Dmitry Stogov

If you measure performance impact using CPU performance counters (VTune,
oprofile, perf) or even better CPU emulator (callgrind) you'll see slight
degradation. It's also clear that it makes some degradation from code
review. 1% difference is invisible because measurement mistake is usually
bigger and also performance may change from build to build because of
different code layout.

Anyway, this is not a stopper, just an issue that would be great to fix.

Thanks. Dmtiry.

On Tue, Feb 10, 2015 at 11:09 AM, Matt Ficken themattfic...@gmail.com
wrote:

FYI, the patch doesn't cause a performance regression.

I built on and tested with IIS/Windows. Performance remains the same for
Wordpress, Symfony and Joomla. Mediawiki actually increased slightly (5%),
so performance is increase/decrease is not an issue here, the language and
engine are.

If you're interested, see:

http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20150209-master_rcaf5521-scalar_type_hints_2_strict_mode-8436.html

Regards
-M

On Mon, Feb 9, 2015 at 6:43 PM, Pierre Joye pierre@gmail.com wrote:

On Feb 10, 2015 1:22 AM, Lars Strojny l...@strojny.net wrote:

Hi Matteo,

sorry for the late response.

On 07 Feb 2015, at 12:46, Matteo Beccati p...@beccati.com wrote:

Maybe it's just me, but I didn't quite understand the point you are
making here. Are you saying that declares are more or less like ini
settings?

Yes, exactly that. The new declare()-statement will fundamentally
change
how the engine behaves and one will have two learn more or less two
flavors
of PHP. Even worse I am forced to use the PHP flavor the person picked
who
changed the declare() statement last.

No. You are not.

cu,
Lars

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-10 Thread Pavel Kouřil

On Wed, Feb 11, 2015 at 7:36 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 On 02/10/2015 07:57 PM, Xinchen Hui wrote:
 am I wrong?!
 seems I am wrong with this, it's a false alarm...  it can restore 
 automatically.

 Yeah, declare() doesn't span files so that isn't a problem.

 My worry is still the lack of type coercion for internal calls. I tested
 it on some apps and it will take quite a bit of tedious and rather
 useless effort to fix these to run in strict mode. Some examples of
 common things that are fatal errors in strict mode:

   ini_set('precision', 14);

   ini_set('display_errors', 1);

   ini_set('display_errors', true);

   ok, not common, but tan(4/2) fatal, tan(5/2) no error

   Wordpress has this function, spot the error:

   function add_magic_quotes( $array ) {
 foreach ( (array) $array as $k = $v ) {
 if ( is_array( $v ) ) {
 $array[$k] = add_magic_quotes( $v );
 } else {
 $array[$k] = addslashes( $v );
 }
 }
 return $array;
   }

   $v may not always be a string (it died with a float for me), so the
   fix is to cast:

 $array[$k] = addslashes( (string)$v );

   Also from Wordpress:

   $formatted = number_format( $number, absint( $decimals ),
 $wp_locale-number_format['decimal_point'],
 $wp_locale-number_format['thousands_sep'] );

   Here number_format() is expecting a float but $number is a string. So
   again, the only real fix is to cast.

   And in Drupal8 *without turning on strict*:

   use Drupal\Component\Utility\String;

   it dies with: Fatal error: string cannot be used as a class name in
 /var/www/drupal/core/includes/bootstrap.inc on line 11

   That String class is everywhere in Drupal. They are going to have a
   fun time with that. See
 https://gist.githubusercontent.com/anonymous/d9252deeeb2aae1a5af5/raw/053155130d22551b1404d0a9b94e27424544b6d1/gistfile1

   From Geeklog:

   if (strtolower($topic) != strtolower($archivetid)) {
 $sql .=  AND ta.tid != '{$archivetid}' ;
   }

   $topic can be null there. Looking at the logic, not really a bug,
   just a natural reliance on null being coerced to 

   Also from Geeklog:

 if( empty( $date )) {
 // Date is empty, get current date/time
 $stamp = time();
 } else if( is_numeric( $date )) {
 // This is a timestamp
 $stamp = $date;
 } else {
 // This is a string representation of a date/time
 $stamp = strtotime( $date );
 }
 // Format the date
 $date = strftime( $dateformat, $stamp );

 strftime() expects an integer for the timestamp there, but as the
 above logic shows, they are expecting a numeric string to be fine.
 No bug, just another forced cast.

 And another number_format() instance where arg1 is not necessarily
 a float. Obviously not a bug, so we have to cast again:

 return number_format( $number, $dc, $ds, $ts );

 In Opencart:

 $this-image = imagecreatetruecolor($width, $height);
 imagecreatetruecolor() expects parameter 1 to be integer, string
 given in /var/www/opencart/system/library/image.php on line 89

 You could argue this is a bug, I guess, but the width and height are
 coming from a database and are integers in the db, but since the db
 returns strings. Another cast...

 I was genuinely hoping to find some bugs with this exercise. I suppose
 it is because I did it on mature projects and at this stage those sorts
 of bugs have already been fixed. But I still fear that people are going
 to want to be enable strictness everywhere and then they will quickly
 learn that they better cast stuff to be safe which makes the whole thing
 rather pointless. And I feel pretty sorry for the Drupal folks. That
 list of 1000+ instances of their String class is going to suck to fix.

 -Rasmus



Helo,

the Drupal thing seems scary.

Also, I realized one thing why I think the strict version is a bad
idea for PHP (in the state PHP is now - in an ideal world I would love
to have nothing but strongly typed PHP, but that's offtopic) - PHP has
many functions that return multiple types, so you cannot do foo(bar())
if bar() has multiple return types. :(

Regards
Pavel Kouril

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-10 Thread Rasmus Lerdorf

On 02/10/2015 07:57 PM, Xinchen Hui wrote:
 am I wrong?!
 seems I am wrong with this, it's a false alarm...  it can restore 
 automatically.

Yeah, declare() doesn't span files so that isn't a problem.

My worry is still the lack of type coercion for internal calls. I tested
it on some apps and it will take quite a bit of tedious and rather
useless effort to fix these to run in strict mode. Some examples of
common things that are fatal errors in strict mode:

  ini_set('precision', 14);

  ini_set('display_errors', 1);

  ini_set('display_errors', true);

  ok, not common, but tan(4/2) fatal, tan(5/2) no error

  Wordpress has this function, spot the error:

  function add_magic_quotes( $array ) {
foreach ( (array) $array as $k = $v ) {
if ( is_array( $v ) ) {
$array[$k] = add_magic_quotes( $v );
} else {
$array[$k] = addslashes( $v );
}
}
return $array;
  }

  $v may not always be a string (it died with a float for me), so the
  fix is to cast:

$array[$k] = addslashes( (string)$v );

  Also from Wordpress:

  $formatted = number_format( $number, absint( $decimals ),
$wp_locale-number_format['decimal_point'],
$wp_locale-number_format['thousands_sep'] );

  Here number_format() is expecting a float but $number is a string. So
  again, the only real fix is to cast.

  And in Drupal8 *without turning on strict*:

  use Drupal\Component\Utility\String;

  it dies with: Fatal error: string cannot be used as a class name in
/var/www/drupal/core/includes/bootstrap.inc on line 11

  That String class is everywhere in Drupal. They are going to have a
  fun time with that. See
https://gist.githubusercontent.com/anonymous/d9252deeeb2aae1a5af5/raw/053155130d22551b1404d0a9b94e27424544b6d1/gistfile1

  From Geeklog:

  if (strtolower($topic) != strtolower($archivetid)) {
$sql .=  AND ta.tid != '{$archivetid}' ;
  }

  $topic can be null there. Looking at the logic, not really a bug,
  just a natural reliance on null being coerced to 

  Also from Geeklog:

if( empty( $date )) {
// Date is empty, get current date/time
$stamp = time();
} else if( is_numeric( $date )) {
// This is a timestamp
$stamp = $date;
} else {
// This is a string representation of a date/time
$stamp = strtotime( $date );
}
// Format the date
$date = strftime( $dateformat, $stamp );

strftime() expects an integer for the timestamp there, but as the
above logic shows, they are expecting a numeric string to be fine.
No bug, just another forced cast.

And another number_format() instance where arg1 is not necessarily
a float. Obviously not a bug, so we have to cast again:

return number_format( $number, $dc, $ds, $ts );

In Opencart:

$this-image = imagecreatetruecolor($width, $height);
imagecreatetruecolor() expects parameter 1 to be integer, string
given in /var/www/opencart/system/library/image.php on line 89

You could argue this is a bug, I guess, but the width and height are
coming from a database and are integers in the db, but since the db
returns strings. Another cast...

I was genuinely hoping to find some bugs with this exercise. I suppose
it is because I did it on mature projects and at this stage those sorts
of bugs have already been fixed. But I still fear that people are going
to want to be enable strictness everywhere and then they will quickly
learn that they better cast stuff to be safe which makes the whole thing
rather pointless. And I feel pretty sorry for the Drupal folks. That
list of 1000+ instances of their String class is going to suck to fix.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Dmitry Stogov

This is definitely not a blocker.
Slight degradation is caused by additional checks on each function call.
Anyway, it's an issue that would be geat to fix.

Thanks. Dmitry.

On Mon, Feb 9, 2015 at 11:17 AM, Pierre Joye pierre@gmail.com wrote:

 On Mon, Feb 9, 2015 at 3:04 PM, Dmitry Stogov dmi...@zend.com wrote:
  this is more or less true. :(
  The proposal is presented in an unfair way to include strict typing
 without
  the ability to vote for weak types only.
 
  Despite of semantic arguments, the implementation is a bit immature and
  introduces slowdown for any code without type hints.

 Hm, I have a bad feeling about this argument popping up again now. I
 did not see any significant perf degradation using common apps but I
 ask Matt to run some tests again using the PR vs master, let discuss
 actual subjective numbers instead of raising the performance impact
 blocker :)

 Cheers,
 Pierre

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Benjamin Coutu

Hello everyone,

(Un)fortunately I do not have voting rights, but here is my (freely expressed) 
50 cents anyways:

I appreciate that Andrea is trying to come up with a one-size-fits-all RFC. 
Nevertheless I believe it is flawed in regards to content as well as formally 
in terms of voting options.

In my view this has become a fight over feature request vs. language 
consistency. I understand that a large part of userland is or would be in favor 
of this RFC - they always prefer new features as long as they are backward 
compatible. You might as well introduce an (configuration/declare) option for 
static typing, and userland would probably cheer. This does not necessarily 
make it a good thing though.

You, @internals, are the guardians of this language and should consider 
intrinsic language consistency as a paramount objective. At the end of the day 
PHP is fundamentally a weakly typed language. Introducing an optionality in how 
the fundamental semantics of the language work (with the declare-proposal) is 
not well thought trough. It is by all means quite hacky - reminds me of 
register-globals, mb-function-overloading, etc. - everything bad about PHP. As 
we all know bad things cannot be revoked easily once introduced.

This doesn't mean strict type hinting cannot be done in a coherent way. There 
have been good (or at least compatible) proposals, e.g. seeing (type) as a 
weak hint and type as a strict hint. This would be somewhat consistent with 
both, casting expressions as well as the existing strict/strong type hints for 
objects. But maybe having both is not the right (PHP) way after all. The only 
thing 100% consistent with the current language semantics would be no type 
hinting at all or some form of weak type hinting. Everything else would be nice 
to have, if (and only if) done right.

Ultimately, and I am sorry to say that, I think this discussion is symptomatic 
for the lack of professionalism among the PHP community, keeping many potential 
contributors (like my colleagues and myself) from actually committing resources 
apart from mere observation. I find it very discouraging that well argued 
opinions of lead developers of this project, such as Andi, Rasmus and Zeev, are 
dismissed so bluntly. I do not recall any instance in the PostgreSQL community 
where Tom Lane or some other senior contributor has been so harshly treated. 
Having the original designers of the language keenly reject this proposal 
should be a concern to all of us, independently of subjective opinion or the 
current voting result.

The honorable (and rational) thing to do would be for the author to retract 
this RFC and thereby postpone the decision (I am aware that the feature freeze 
looms!). This is so important for the future of PHP, so let's don't rush it, 
but try to do it right!

Cheers,

Ben

== Original ==
From: Matthew Leverton lever...@gmail.com
To: Zeev Suraski z...@zend.com
Date: Mon, 09 Feb 2015 05:20:25 +0100
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints



On Sun, Feb 8, 2015 at 3:22 PM, Zeev Suraski z...@zend.com wrote:
 I'm well aware of it as I wrote that policy.  The goal of the policy was to
 prevent a situation where a temporary majority can introduce features into
 the language that would later on be impossible to reverse.  It's not by any
 stretch a good mechanism to solve controversial votes, which again, should
 ideally be avoided as much as possible.  It's just that there isn't a better
 mechanism.

I know I'm unfairly paraphrasing you, but it sounds like you are
saying that for things that you don't have strong feelings about, then
you're fine if the others vote amongst themselves. But for things that
matter to you, you want to reserve the right to prevent change. Is
there a way to fairly describe what you consider too controversial to
vote on?

The problem I see with votes for this type of feature is that you
probably have a breakdown of something like:

- 10% of people don't want scalar type hints
- 20% of people want both, but 50% of them would vote for either weak or strong
- 35% of people want strict, but 80% of them are fine with weak
- 35% of people want weak, but 80% of them are fine with strong

So if a strict-only vote happens first, you get 73% to say yes. If
weak-only vote happens first, you get 73% to say yes.

(I'm obviously just making up these numbers with no scientific basis,
but I think the principle is valid.)

The only way to be fair IMO is to hold a vote where you rank those
four options (weak, strong, both, neither) and hold an instant run-off
vote where the first majority wins. And if 'neither' wins, then agree
that the topic cannot be revisited until next major version, so that
everybody can rest for 5 years. ;)

--
Matthew Leverton


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

RE: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Zeev Suraski

 -Original Message-
 From: Andrea Faulds [mailto:a...@ajf.me]
 Sent: Monday, February 09, 2015 12:44 PM
 To: Zeev Suraski
 Cc: Jordi Boggiano; internals@lists.php.net
 Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints

 Hi,

  On 9 Feb 2015, at 03:48, Zeev Suraski z...@zend.com wrote:

  A - has pretty much everybody agreeing with is a good idea.  Nobody
 objects to it.  It's under consensus.

 This isn't true. I've explained why it isn't true several times. Maybe
you are
 suffering from confirmation bias or something, but there is no such
 consensus. Quite a few internals contributors liked v0.1. Quite a few
didn't.
 I've gone and evidenced this before in replies sent directly to you.

Andrea,

I'll make an absolute last attempt to explain what I'm saying, after that
we can agree to disagree.  We probably interpret the same facts
differently.

Fact is, there were very few people who said that weak types are *bad*
(although Sebastian seems to fall in that category).  The vast majority of
feedback that 'opposed' weak typing, didn't really oppose weak typing at
all.  What it opposed was, rather, the lack of introducing strict typing.
That is clearly not the same thing, which is why the fact there were
people who opposed v0.1 of the RFC does not equate with people opposing
weak typing, not at all.

Each and every person that voted in favor of the v0.3 RFC, voted in favor
of weak typing.  Weak typing is not only a key element of that RFC - it's
even the default behavior.  In addition to everyone who voted in favor of
the v0.3 RFC, many - most probably most of the people who voted against
it- are in favor of the weak typing API.  If you combine the two groups,
you're going to get to nearly 100% support, or arguably, 'lack of
opposition', to the weak typing proposal.

So I stand by my comment, which has nothing to do with confirmation bias
but is based on simple facts, that there's consensus (or near consensus)
about weak typing being acceptable into the language.   Of course, many of
the people in the strict typing camp are not actively supportive of the
weak typing part, but they also don't oppose it.  Again, the fact they
voted in favor of adding them attests to that.

The controversy is exclusively around strict typing.  It goes both ways -
proponents of strict typing feel very passionate about having to introduce
it into the language;  Opponents seem to feel equally passionate about not
adding them.

I hope that clarifies my previous statements and put that part of the
discussion to rest.

Zeev

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Matteo Beccati


On 09/02/2015 15:50, Pierre Joye wrote:

On Feb 9, 2015 8:52 PM, Sebastian Bergmann sebast...@php.net wrote:

  then the corresponding check must be strict. But since that strictness
  does not align with the spirit of PHP I much rather have no support
  for scalars than one that is not strict.


Not strict? You loose me here.


I guess he meant:  no support for scalar type hints than one that is 
not strict.



Cheers
--
Matteo Beccati

Development  Consulting - http://www.beccati.com/

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

RE: [PHP-DEV] [VOTE] Scalar Type Hints

On Feb 10, 2015 12:03 AM, Zeev Suraski z...@zend.com wrote:

  -Original Message-
  From: Andrea Faulds [mailto:a...@ajf.me]
  Sent: Monday, February 09, 2015 12:44 PM
  To: Zeev Suraski
  Cc: Jordi Boggiano; internals@lists.php.net
  Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints

  Hi,

   On 9 Feb 2015, at 03:48, Zeev Suraski z...@zend.com wrote:

   A - has pretty much everybody agreeing with is a good idea.  Nobody
  objects to it.  It's under consensus.

  This isn't true. I've explained why it isn't true several times. Maybe
 you are
  suffering from confirmation bias or something, but there is no such
  consensus. Quite a few internals contributors liked v0.1. Quite a few
 didn't.
  I've gone and evidenced this before in replies sent directly to you.

 Andrea,

 I'll make an absolute last attempt to explain what I'm saying, after that
 we can agree to disagree.  We probably interpret the same facts
 differently.

 Fact is, there were very few people who said that weak types are *bad*
 (although Sebastian seems to fall in that category).  The vast majority of
 feedback that 'opposed' weak typing, didn't really oppose weak typing at
 all.

Oh wait. So the waste majority actually willing this RFC actually want
another? This is fantastic

Anyway, no worry, opposed ppl managed to get this amazing RFC shot down.
Prepare your own to do exactly what you want, how you want, many will
accept it as default choice despite it being a poor choice. A deja vu
feeling is popping up in my mind. Well played.

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Lars Strojny

Hi Matteo,

sorry for the late response.

 On 07 Feb 2015, at 12:46, Matteo Beccati p...@beccati.com wrote:
 
 Maybe it's just me, but I didn't quite understand the point you are making 
 here. Are you saying that declares are more or less like ini settings?

Yes, exactly that. The new declare()-statement will fundamentally change how 
the engine behaves and one will have two learn more or less two flavors of PHP. 
Even worse I am forced to use the PHP flavor the person picked who changed the 
declare() statement last.

cu,
Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread André Rømcke

On 09 Feb 2015, at 19:24 , guilhermebla...@gmail.com wrote:
 
 Hi Andrea,
 
 I totally see your viewpoint. That's why initially I voted YES, because
 your proposal somehow makes sense.
 My when I thought over and use a weak/strict boolean type conversion on my
 own brain, I came to the conclusion my real wish does not get fully
 addressed with a YES, leading me to switch my vote.
 I really wanted to expose the motivation of my change here, so everyone is
 aware that I do love strict typing, and I really want this in for PHP, but
 not in this RFC way.


To me this is the best compromise that can be made here.
In case of boolean: if you specify boolean, boolean is what you get, no matter 
what user of your library do.

So you are in full control here!
You are not, however, in control over other peoples code, which you shouldn’t 
be anyway. After all you didn’t write it.

The RFC quite elegantly allows both strict and weak camps to be pleased, 
bikeshedding on declare() aside.
So it is a pity people in those camps don’t see that, as this is rather 
overdue* feature.


Best,
André


* It is a feature that allows us all to write more reliable, shorter, and 
better self documented code.
  We got it for all other types up until now, only scalars missing.

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Arvids Godjuks

I actually have a question, that Ferenc touched on, but it never got any
discussion.

How, actually, the declare will work with concatenated PHP files? It's
quite a common practice to put the files into packages, that require
minimal amounts of includes for performance reasons.
Declare is required to be a the top of a file as a first statement. So, if
I have like 10 packages from composer written in different styles, how
should I actually combine them? Stripping the declare from each file and
putting a single declare with the type hint level I want? What will happen
if a library is written for weak type hints ends up in strict type hint
mode? Or the other way around? Isn't it gonna be a mess?

Thanks,
Arvids.

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Mon, Feb 9, 2015 at 3:02 PM, Arvids Godjuks arvids.godj...@gmail.com wrote:
 I actually have a question, that Ferenc touched on, but it never got any
 discussion.

 How, actually, the declare will work with concatenated PHP files? It's
 quite a common practice to put the files into packages, that require
 minimal amounts of includes for performance reasons.
 Declare is required to be a the top of a file as a first statement. So, if
 I have like 10 packages from composer written in different styles, how
 should I actually combine them? Stripping the declare from each file and
 putting a single declare with the type hint level I want? What will happen
 if a library is written for weak type hints ends up in strict type hint
 mode? Or the other way around? Isn't it gonna be a mess?

How do you do it for namespaces? This is the same issue.


Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Dmitry Stogov

this is more or less true. :(
The proposal is presented in an unfair way to include strict typing without
the ability to vote for weak types only.

Despite of semantic arguments, the implementation is a bit immature and
introduces slowdown for any code without type hints.

Thanks. Dmitry.



On Mon, Feb 9, 2015 at 7:20 AM, Matthew Leverton lever...@gmail.com wrote:

 On Sun, Feb 8, 2015 at 3:22 PM, Zeev Suraski z...@zend.com wrote:
  I'm well aware of it as I wrote that policy.  The goal of the policy was
 to
  prevent a situation where a temporary majority can introduce features
 into
  the language that would later on be impossible to reverse.  It's not by
 any
  stretch a good mechanism to solve controversial votes, which again,
 should
  ideally be avoided as much as possible.  It's just that there isn't a
 better
  mechanism.
 
 I know I'm unfairly paraphrasing you, but it sounds like you are
 saying that for things that you don't have strong feelings about, then
 you're fine if the others vote amongst themselves. But for things that
 matter to you, you want to reserve the right to prevent change. Is
 there a way to fairly describe what you consider too controversial to
 vote on?

 The problem I see with votes for this type of feature is that you
 probably have a breakdown of something like:

 - 10% of people don't want scalar type hints
 - 20% of people want both, but 50% of them would vote for either weak or
 strong
 - 35% of people want strict, but 80% of them are fine with weak
 - 35% of people want weak, but 80% of them are fine with strong

 So if a strict-only vote happens first, you get 73% to say yes. If
 weak-only vote happens first, you get 73% to say yes.

 (I'm obviously just making up these numbers with no scientific basis,
 but I think the principle is valid.)

 The only way to be fair IMO is to hold a vote where you rank those
 four options (weak, strong, both, neither) and hold an instant run-off
 vote where the first majority wins. And if 'neither' wins, then agree
 that the topic cannot be revisited until next major version, so that
 everybody can rest for 5 years. ;)

 --
 Matthew Leverton

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Mon, Feb 9, 2015 at 3:04 PM, Dmitry Stogov dmi...@zend.com wrote:
 this is more or less true. :(
 The proposal is presented in an unfair way to include strict typing without
 the ability to vote for weak types only.

 Despite of semantic arguments, the implementation is a bit immature and
 introduces slowdown for any code without type hints.

Hm, I have a bad feeling about this argument popping up again now. I
did not see any significant perf degradation using common apps but I
ask Matt to run some tests again using the PR vs master, let discuss
actual subjective numbers instead of raising the performance impact
blocker :)

Cheers,
Pierre

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Pavel Kouřil

On Mon, Feb 9, 2015 at 9:04 AM, Dmitry Stogov dmi...@zend.com wrote:
 this is more or less true. :(
 The proposal is presented in an unfair way to include strict typing without
 the ability to vote for weak types only.

 Despite of semantic arguments, the implementation is a bit immature and
 introduces slowdown for any code without type hints.

 Thanks. Dmitry.



This is something I mentioned several times - there should be two
votes. One for weak types and one for adding the strict typing on the
weak typing as a bonus. Not bundling it into one voting, it makes it
feel forced.


Pavel Kouril

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Mon, Feb 9, 2015 at 3:19 PM, Pavel Kouřil pajou...@gmail.com wrote:
 On Mon, Feb 9, 2015 at 9:04 AM, Dmitry Stogov dmi...@zend.com wrote:
 this is more or less true. :(
 The proposal is presented in an unfair way to include strict typing without
 the ability to vote for weak types only.

 Despite of semantic arguments, the implementation is a bit immature and
 introduces slowdown for any code without type hints.

 Thanks. Dmitry.



 This is something I mentioned several times - there should be two
 votes. One for weak types and one for adding the strict typing on the
 weak typing as a bonus. Not bundling it into one voting, it makes it
 feel forced.


I am not saying I want one or the other (I have voted and now only
focus on solving possible tech issues we may find) but trying to be
fair with Andrea's RFC and amazing effort:

What you ask is basically part of the RFC already, your code can be
strict free if you wish to, or it will be by default. Only issue is
the massive misunderstanding behind the declare(strict) thing.

Cheers,
Pierre

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Pavel Kouřil

On Mon, Feb 9, 2015 at 9:22 AM, Pierre Joye pierre@gmail.com wrote:


 I am not saying I want one or the other (I have voted and now only
 focus on solving possible tech issues we may find) but trying to be
 fair with Andrea's RFC and amazing effort:

 What you ask is basically part of the RFC already, your code can be
 strict free if you wish to, or it will be by default. Only issue is
 the massive misunderstanding behind the declare(strict) thing.

 Cheers,
 Pierre

I'm not saying one or the other - I mean two votes, one for the
basic weak typing and if it passes, then vote for adding the
declareable optional strict typing. Now it is unfortunately both or
neither.

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Mon, Feb 9, 2015 at 3:30 PM, Pavel Kouřil pajou...@gmail.com wrote:
 On Mon, Feb 9, 2015 at 9:22 AM, Pierre Joye pierre@gmail.com wrote:


 I am not saying I want one or the other (I have voted and now only
 focus on solving possible tech issues we may find) but trying to be
 fair with Andrea's RFC and amazing effort:

 What you ask is basically part of the RFC already, your code can be
 strict free if you wish to, or it will be by default. Only issue is
 the massive misunderstanding behind the declare(strict) thing.

 Cheers,
 Pierre

 I'm not saying one or the other - I mean two votes, one for the
 basic weak typing and if it passes, then vote for adding the
 declareable optional strict typing. Now it is unfortunately both or
 neither.

because you have both already. Your code is not affected unless you
use strict=1, even if the libs your code relies on actually use
strict=1. In other words, this RFC proposes both worlds in one shot. I
see the votes for two as redundant or killing the root idea behind
this RFC.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Andrey Andreev

Hi,

On Mon, Feb 9, 2015 at 7:22 PM, Jordi Boggiano j.boggi...@seld.be wrote:

 And that is exactly why this RFC is great, since it lets the
 strict-proponents have their strict types in their files, but those
 preferring weak ones can remain in the default weak mode, never see an ugly
 declare(), and still call strict code in weak mode.

 That is why I don't quite understand the no votes coming from weak-hints
 proponents. Unless of course you would prefer to pass weak-only v0.1 and
 then shoot down any attempt at strict hints. That strikes me as quite
 selfish though, given the strict-proponents isn't such a tiny group of
 people.

 And then there are the people sitting somewhere in between the black and
 white camps. Those that would like to use strict sometimes for some critical
 code paths, and for them the proposed solution is quite good as well.


I am in the between black and white camp and this RFC doesn't give
me what I want, nor did the 0.1 version of it.
I would vote 'no' on both if I had voting privileges.

Please, all, stop speculating and just let the votes count.

Cheers,
Andrey.

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread guilhermebla...@gmail.com

Hi,

I read again and again the RFC and I just decided to switch my vote.
Originally a YES voter, I'm now a NO voter. I still want strict types
to exist in PHP, and not only at the end-user level, but also at the
internals level (I can see so many optimizations around...).
However, I think it's not an INI setting or a per file operation. I
consider it should be (at the current PHP's pace) a heavily flexible
support. I tend to agree that if you put string in its definition, you
don't want a weak type, but strict type, the same way when you put MyClass
instead of nothing.

That's why I don't agree with the declare or use strict or ?php strict.
If I say string $foo, I want a string, not a converted value. By
accepting this fact, makes easier in the future to make OO primitive types
if we wish, and also makes everything easier for everyone... if you have
foo(string $name), you expect strict type... if you want weak type,
foo($name). All code will work as is today, no BC breaks.

That's my 2 cents... now time to update my vote in RFC.

[]s,


On Mon, Feb 9, 2015 at 1:02 PM, Andrey Andreev n...@devilix.net wrote:

 Hi,

 On Mon, Feb 9, 2015 at 7:22 PM, Jordi Boggiano j.boggi...@seld.be wrote:
 
  And that is exactly why this RFC is great, since it lets the
  strict-proponents have their strict types in their files, but those
  preferring weak ones can remain in the default weak mode, never see an
 ugly
  declare(), and still call strict code in weak mode.
 
  That is why I don't quite understand the no votes coming from
 weak-hints
  proponents. Unless of course you would prefer to pass weak-only v0.1 and
  then shoot down any attempt at strict hints. That strikes me as quite
  selfish though, given the strict-proponents isn't such a tiny group of
  people.
 
  And then there are the people sitting somewhere in between the black and
  white camps. Those that would like to use strict sometimes for some
 critical
  code paths, and for them the proposed solution is quite good as well.
 

 I am in the between black and white camp and this RFC doesn't give
 me what I want, nor did the 0.1 version of it.
 I would vote 'no' on both if I had voting privileges.

 Please, all, stop speculating and just let the votes count.

 Cheers,
 Andrey.

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




-- 
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hi Zeev,

 On 9 Feb 2015, at 17:03, Zeev Suraski z...@zend.com wrote:
 
 I'll make an absolute last attempt to explain what I'm saying, after that
 we can agree to disagree.  We probably interpret the same facts
 differently.
 
 Fact is, there were very few people who said that weak types are *bad*
 (although Sebastian seems to fall in that category).  The vast majority of
 feedback that 'opposed' weak typing, didn't really oppose weak typing at
 all.  What it opposed was, rather, the lack of introducing strict typing.
 That is clearly not the same thing, which is why the fact there were
 people who opposed v0.1 of the RFC does not equate with people opposing
 weak typing, not at all.
 
 Each and every person that voted in favor of the v0.3 RFC, voted in favor
 of weak typing.  Weak typing is not only a key element of that RFC - it's
 even the default behavior.  In addition to everyone who voted in favor of
 the v0.3 RFC, many - most probably most of the people who voted against
 it- are in favor of the weak typing API.  If you combine the two groups,
 you're going to get to nearly 100% support, or arguably, 'lack of
 opposition', to the weak typing proposal.

First off, it’s really unfair to claim that merely because someone votes for 
this RFC, that they are okay with weak typing. It’s a compromise proposal: I’m 
not a big fan of weak typing, not by any means, and plenty of other people 
aren’t either, but this RFC allows me to use strict typing and others to use 
weak typing, without us getting in each other’s way. So, I am in favour of this 
RFC. I *do not like* weak typing. But I am willing to vote for and push for 
this RFC, if it means we’ll get scalar types somehow (and, crucially, it allows 
*strict* scalar types). People who are in favour of this RFC are *not* 
necessarily in favour of weak types, or adding weak types on their own.

Anyway, to the main point. I’m pretty sure that you’re wrong in saying that the 
vast majority of the people who opposed the introduction of weak scalar types, 
and *only* weak scalar types in the v0.1 RFC, were actually okay with weak 
typing. That does not go with my experiences at all. From what I have seen, a 
large number of people are opposed to weakly-typed parameters, period.

But let’s assume that you’re correct for a moment. Let’s say that, 
hypothetically, 100% of the people in the v0.1 thread (absolute consensus, 
then) had no opposition to the idea of weak typing, and the only complaint 
anyone had was that strict typing wasn’t also being added.

This doesn’t help your case. In fact, it hurts it.

Firstly, while there may be this hypothetical consensus around weak types, the 
v0.1 RFC showed there was definitely NOT consensus around adding weak types *on 
their own*. Yet that was what you are arguing: that their would be consensus, 
or is consensus, around just adding weak types. So, merely adding weak types, 
and not strict types, is not something there’s a consensus on, and is not 
something everyone can agree on, despite what you have been arguing.

Secondly, you are saying that the only opposition to v0.1 was that it did not 
also introduce strict types. So, therefore, this new version of the RFC which 
introduces strict typing alongside weak typing, should surely be more popular, 
no?

I do not understand your logic.

--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread guilhermebla...@gmail.com

Hi Andrea,

I totally see your viewpoint. That's why initially I voted YES, because
your proposal somehow makes sense.
My when I thought over and use a weak/strict boolean type conversion on my
own brain, I came to the conclusion my real wish does not get fully
addressed with a YES, leading me to switch my vote.
I really wanted to expose the motivation of my change here, so everyone is
aware that I do love strict typing, and I really want this in for PHP, but
not in this RFC way.

[]s,

On Mon, Feb 9, 2015 at 1:19 PM, Andrea Faulds a...@ajf.me wrote:

 Hi Guilherme,

  On 9 Feb 2015, at 18:12, guilhermebla...@gmail.com wrote:
 
  I read again and again the RFC and I just decided to switch my vote.
  Originally a YES voter, I'm now a NO voter. I still want strict types
  to exist in PHP, and not only at the end-user level, but also at the
  internals level (I can see so many optimizations around...).
  However, I think it's not an INI setting or a per file operation. I
  consider it should be (at the current PHP's pace) a heavily flexible
  support. I tend to agree that if you put string in its definition, you
  don't want a weak type, but strict type, the same way when you put
 MyClass
  instead of nothing.
 
  That's why I don't agree with the declare or use strict or ?php
 strict.
  If I say string $foo, I want a string, not a converted value. By
  accepting this fact, makes easier in the future to make OO primitive
 types
  if we wish, and also makes everything easier for everyone... if you have
  foo(string $name), you expect strict type... if you want weak type,
  foo($name). All code will work as is today, no BC breaks.
 
  That's my 2 cents... now time to update my vote in RFC.

 I can understand that viewpoint, but it’s not terribly kind on your users.
 You’re basically saying that you want to force people who’d prefer weak
 typing to use strict typing if they use your API. It’s doing this which
 this RFC is designed to prevent. I don’t think allowing people to force
 their way on their users is a good way to deal with the lack of weak or
 strict consensus in the community, no matter whether it’s nice for API
 design or not.

 Thanks.

 --
 Andrea Faulds
 http://ajf.me/







-- 
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Philip Sturgeon

On Mon, Feb 9, 2015 at 1:22 PM, Lars Strojny l...@strojny.net wrote:
 Hi Matteo,

 sorry for the late response.

 On 07 Feb 2015, at 12:46, Matteo Beccati p...@beccati.com wrote:

 Maybe it's just me, but I didn't quite understand the point you are making 
 here. Are you saying that declares are more or less like ini settings?

 Yes, exactly that. The new declare()-statement will fundamentally change how 
 the engine behaves and one will have two learn more or less two flavors of 
 PHP. Even worse I am forced to use the PHP flavor the person picked who 
 changed the declare() statement last.

 cu,
 Lars

This is strange for me to understand but I do see it come up a lot.

if you have foo(string $name), you expect strict type... if you want
weak type, foo($name). All code will work as is today, no BC breaks.

No. If I have foo(string $name), I expect a string. I don't care if
its strong or weak, I just want a string. The weak or strong bit is up
to the user, which is why they're the ones holding the switch.

While I understand the wish to preach best practices to the PHP
community in general - because heck knows some people need it - this
is more of an entry for phptherightway.com than the job of every
single library author to try and force the community ot use strict
typing one library at a time.

The function author doesn't need to care if its strong or weak. They
just need to care that they have the right type. And they will, every
time.

Using foo($name) will give me the wrong types, so no thanks on that :)

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hi,

 On 9 Feb 2015, at 18:22, Lars Strojny l...@strojny.net wrote:
 
 On 07 Feb 2015, at 12:46, Matteo Beccati p...@beccati.com wrote:
 
 Maybe it's just me, but I didn't quite understand the point you are making 
 here. Are you saying that declares are more or less like ini settings?
 
 Yes, exactly that. The new declare()-statement will fundamentally change how 
 the engine behaves

It’s a relatively minor change. It changes how arguments and return values are 
type-checked, that’s all. The patch isn’t that complex.

 and one will have two learn more or less two flavors of PHP.

Hardly, the differences are not that big. One’s slightly stricter when checking 
arguments and return values, but that’s it. It’s not two completely different 
worlds, it’s a minor detail of personal preference.

 Even worse I am forced to use the PHP flavor the person picked who changed 
 the declare() statement last.

Well, yes, in a project with multiple people, you must conform to the project 
style guide and such, that’s hardly unusual.

--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Philip Sturgeon

On Mon, Feb 9, 2015 at 12:03 PM, Zeev Suraski z...@zend.com wrote:
 -Original Message-
 From: Andrea Faulds [mailto:a...@ajf.me]
 Sent: Monday, February 09, 2015 12:44 PM
 To: Zeev Suraski
 Cc: Jordi Boggiano; internals@lists.php.net
 Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints

 Hi,

  On 9 Feb 2015, at 03:48, Zeev Suraski z...@zend.com wrote:

  A - has pretty much everybody agreeing with is a good idea.  Nobody
 objects to it.  It's under consensus.

 This isn't true. I've explained why it isn't true several times. Maybe
 you are
 suffering from confirmation bias or something, but there is no such
 consensus. Quite a few internals contributors liked v0.1. Quite a few
 didn't.
 I've gone and evidenced this before in replies sent directly to you.

 Andrea,

 I'll make an absolute last attempt to explain what I'm saying, after that
 we can agree to disagree.  We probably interpret the same facts
 differently.

 Fact is, there were very few people who said that weak types are *bad*
 (although Sebastian seems to fall in that category).  The vast majority of
 feedback that 'opposed' weak typing, didn't really oppose weak typing at
 all.  What it opposed was, rather, the lack of introducing strict typing.
 That is clearly not the same thing, which is why the fact there were
 people who opposed v0.1 of the RFC does not equate with people opposing
 weak typing, not at all.

 Each and every person that voted in favor of the v0.3 RFC, voted in favor
 of weak typing.  Weak typing is not only a key element of that RFC - it's
 even the default behavior.  In addition to everyone who voted in favor of
 the v0.3 RFC, many - most probably most of the people who voted against
 it- are in favor of the weak typing API.  If you combine the two groups,
 you're going to get to nearly 100% support, or arguably, 'lack of
 opposition', to the weak typing proposal.

Woah there Zeev, please take your words out of my mouth, and out of
the mouths of 48 other people.

I voted Yes for this RFC because default weak and optional strict is a
perfectly PHP-way™ to get this job done.

You really have to stop speaking for other people, or this
conversation is going to go off the rails for eternity. We can speak
for ourselves.

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hi Guilherme,

 On 9 Feb 2015, at 18:12, guilhermebla...@gmail.com wrote:
 
 I read again and again the RFC and I just decided to switch my vote.
 Originally a YES voter, I'm now a NO voter. I still want strict types
 to exist in PHP, and not only at the end-user level, but also at the
 internals level (I can see so many optimizations around...).
 However, I think it's not an INI setting or a per file operation. I
 consider it should be (at the current PHP's pace) a heavily flexible
 support. I tend to agree that if you put string in its definition, you
 don't want a weak type, but strict type, the same way when you put MyClass
 instead of nothing.
 
 That's why I don't agree with the declare or use strict or ?php strict.
 If I say string $foo, I want a string, not a converted value. By
 accepting this fact, makes easier in the future to make OO primitive types
 if we wish, and also makes everything easier for everyone... if you have
 foo(string $name), you expect strict type... if you want weak type,
 foo($name). All code will work as is today, no BC breaks.
 
 That's my 2 cents... now time to update my vote in RFC.

I can understand that viewpoint, but it’s not terribly kind on your users. 
You’re basically saying that you want to force people who’d prefer weak typing 
to use strict typing if they use your API. It’s doing this which this RFC is 
designed to prevent. I don’t think allowing people to force their way on their 
users is a good way to deal with the lack of weak or strict consensus in the 
community, no matter whether it’s nice for API design or not.

Thanks.

--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Jordi Boggiano


On 09/02/2015 17:03, Zeev Suraski wrote:

Fact is, there were very few people who said that weak types are *bad*
(although Sebastian seems to fall in that category).  The vast majority of
feedback that 'opposed' weak typing, didn't really oppose weak typing at
all.  What it opposed was, rather, the lack of introducing strict typing.
That is clearly not the same thing, which is why the fact there were
people who opposed v0.1 of the RFC does not equate with people opposing
weak typing, not at all.


The problem is: what's in it for the strict camp to vote yes for a v0.1 
that offers no guarantee that strict hints will be added later nor in 
which form that would happen?


If there is no guarantee, having weak hints in the language is actually 
a bad thing for them since it might mean strict ones never materialize.



Each and every person that voted in favor of the v0.3 RFC, voted in favor
of weak typing.  Weak typing is not only a key element of that RFC - it's
even the default behavior.  In addition to everyone who voted in favor of
the v0.3 RFC, many - most probably most of the people who voted against
it- are in favor of the weak typing API.  If you combine the two groups,
you're going to get to nearly 100% support, or arguably, 'lack of
opposition', to the weak typing proposal.


As per my answers above, I don't think this is true, unless they have no 
clue how politics work.



The controversy is exclusively around strict typing.  It goes both ways -
proponents of strict typing feel very passionate about having to introduce
it into the language;  Opponents seem to feel equally passionate about not
adding them.


And that is exactly why this RFC is great, since it lets the 
strict-proponents have their strict types in their files, but those 
preferring weak ones can remain in the default weak mode, never see an 
ugly declare(), and still call strict code in weak mode.


That is why I don't quite understand the no votes coming from 
weak-hints proponents. Unless of course you would prefer to pass 
weak-only v0.1 and then shoot down any attempt at strict hints. That 
strikes me as quite selfish though, given the strict-proponents isn't 
such a tiny group of people.


And then there are the people sitting somewhere in between the black and 
white camps. Those that would like to use strict sometimes for some 
critical code paths, and for them the proposed solution is quite good as 
well.


Cheers

--
Jordi Boggiano
@seldaek - http://nelm.io/jordi

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hi,

 On 9 Feb 2015, at 03:48, Zeev Suraski z...@zend.com wrote:
 
 A - has pretty much everybody agreeing with is a good idea.  Nobody objects 
 to it.  It's under consensus.

This isn't true. I've explained why it isn't true several times. Maybe you are 
suffering from confirmation bias or something, but there is no such 
consensus. Quite a few internals contributors liked v0.1. Quite a few didn't. 
I've gone and evidenced this before in replies sent directly to you. 

In addition, the reaction from the wider community was largely negative.

 B - has a large number of people thinking it's alien to PHP, and has many 
 people objecting to it.

B also has a large number of supporters because it is a pragmatic compromise.

A also had a large number of detractors.

 The vote is on A+B.

No it isn't.

You are claiming, as I understand it, that:


* Weak typing has consensus (it doesn't)
* Strict typing is entirely controversial (it has many supporters, however)
* This proposal including both somehow nullifies the argument that weak typing 
lacks consensus (it doesn't - someone is free to oppose the addition of 
something in isolation yet support its addition in combination)

The truth of the matter is this. There are at least two approaches to scalar 
type hint behaviour: weak and strict. Both are highly controversial. The 
addition of either exclusively, is controversial. The addition of both 
together, is controversial. The addition of stricter weak typing, is 
controversial. The issue of scalar type hints is highly controversial in 
general for these reasons.

There is no consensus whatsoever. To suggest there is would be to grossly 
exaggerate.

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hi,

 On 9 Feb 2015, at 08:04, Dmitry Stogov dmi...@zend.com wrote:
 
 this is more or less true. :(
 The proposal is presented in an unfair way to include strict typing without
 the ability to vote for weak types only.

Oddly, nobody seems to complain that it's unfair if I side with the weak typing 
camp, despite that being equally unfair.

 Despite of semantic arguments, the implementation is a bit immature and
 introduces slowdown for any code without type hints.

The implementation could do with improvement, this is true. However I suspect 
any slowdown is minor at best, and this could be dealt with in future. The RFC 
is more about the language change than the implementation.

--
Andrea Faulds
http://ajf.me/

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Lester Caine

On 09/02/15 10:44, Andrea Faulds wrote:
 There is no consensus whatsoever. To suggest there is would be to grossly 
 exaggerate.

I am just happy that to force change through a 2/3rds majority is
required. If there was a consensus then the debate would not have been
so extensive, but while the continuing chant of 'you don't have to use
it' prevails, we end up with a lot of additional overheads just to keep
a small number of users happy.

In the case of this vote, the vote itself IS flawed as two different
additions ARE being pushed together, and personally I feel that the yes
vote IS being distorted by those who want weak typing and could not care
less about strong typing. That neither of the proposed solutions
actually provide a complete solution for either camp is a shame.

I do understand why many of these extras can't simply be user selectable
extensions, but just how many of the 'core' modules are actually needed
for a basic PHP server. Yes I need 'typing' but I need a version that
handles the types I am using not some rather limited subset, and
improvements in PHP7 has increased the need for a proper typing system
which scalar type hints does nothing to address :(

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Pascal MARTIN




Le 05/02/2015 21:14, Andrea Faulds a écrit :

At long last, I’m going to put the RFC to a vote. It’s been long enough - I 
don’t think there needs to be, or will be, much further discussion.

I’d like to make sure that everyone voting understands the RFC fully. Please 
read the RFC in full: the details are important. And if  anyone has any 
questions or uncertainties, please ask them before voting. I am very happy to 
answer them.

I would urge everyone who wants type hints to vote for this RFC. It is not a 
perfect solution, but there can be no perfect solution to this issue. However, 
I think it is better than most of the alternatives suggested thus far - see the 
rationale section, and previous discussions. Crucially, this RFC would keep PHP 
a weakly-typed language, and not force either strict typing, nor weak typing, 
on anyone who does not want it. It would allow the addition of type hints to 
existing codebases. It would not create a situation where userland functions 
are strict yet internal functions are not, because the strict mode affects 
both. I’ve tested the implementation myself on my own code, and it worked well, 
providing benefits other proposals would not have given (see my previous post 
about my experiences).



Hi,

Just to let you know, I've written a post about this RFC on my blog, 
trying to present what it brings to the table and to explain why I like it:


http://blog.pascal-martin.fr/post/in-favor-of-rfc-scalar-type-hints.html

Maybe another way of presenting things might help some people here to 
decide whether or not they think this RFC is helpful.


Even if I've published this earlier today, I've written it between 
Thursday and Friday, so it doesn't really take into account the new 
ideas (new syntax propositions) that have been posted since.


Please note this is *my* personal opinion, and doesn't necessarily 
reflect the opinion of any organization I am affiliated with.


Pascal.

--
Pascal MARTIN
http://blog.pascal-martin.fr
@pascal_martin

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Andi Gutmans

 On Feb 7, 2015, at 7:52 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 
 On 02/07/2015 09:51 PM, Andrea Faulds wrote:
 tan(1);
 echo strstr(test, est, 1);
 
 Banning int-float and float-int is both a pain point and sometimes a 
 life-saver. It’s annoying that tan(1) doesn’t work. On the other hand, you 
 discover if your ints floats would be silently truncated (as I did with 
 PictoSwap).
 
 I wouldn’t say that int-string not working is a problem, though. Seeing 
 something like strstr(“test”, “est”, 1); is rather confusing. Looking at it, 
 I’d think the third parameter is some sort of number for you to want to pass 
 an integer to it. If I want a string, I’ll use one.
 
 This isn't int-string. This is int-boolean. The 3rd arg to strstr() is
 a boolean and passing 1 instead of true makes it blow up. It is very
 very common for people to pass 0 or 1 in place of true/false to all
 sorts of things in PHP.


Thanks for those relevant examples.
I think it’s also worth emphasizing that in C people frequently work around 
this by forcing casts. The value of strict typing diminishes quickly and the 
code ends up being less readable.

I think in PHP this is going to be even more so due to the reasons Rasmus 
states. We have *a lot* of places like this which will lead to unnatural acts 
and code which is no more strict than it was before (just not as pretty).

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Sebastian Bergmann

Am 07.02.2015 um 02:08 schrieb Sebastian Bergmann:
 After reading your email, Nikita, I deleted my vote (it was no before).
 I will review the RFC again, with your arguments (and others) in mind
 and maybe I'll come to a different conclusion.

 I have voted (no) again.

 I still think that if we add support for scalars in type declarations
 then the corresponding check must be strict. But since that strictness
 does not align with the spirit of PHP I much rather have no support
 for scalars than one that is not strict.

 Maybe built-in classes such as String, Integer, Float, Boolean that know
 how convert themselves to the corresponding scalar type are a viable
 approach that is worth exploring.

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Umberto Salsi

a...@ajf.me (Andrea Faulds) wrote:

 * Always allowing implicit conversions from int to float is sometimes
 going to cause data loss, so it may also be reasonable for PHP to
 prevent this specific case

IMHO, automatic conversion int -- float is perfectly reasonable because:
1) int can always be converted to float, possibly loosing some less
significant digists (int on 64-bit PCs can contain up to 19 digits,
float contains up to about 16 digits);
2) the called function is already aware (according to the contract of its
interface accepting float) that the passed value is an approximated
representation of a number, and should also be aware of all the
limitations of the floating-point arithmetic.

 * Requiring an exact type match has the least mental overhead, and
 allows types to be checked at compile-time

Agree with the first part of the sentence (saving neural cells, specially
when you have to understand someone else's code...), but there is no
need for a compiler to garantee the type-safety of a program: static
validation can be used right now on PHP using DocBlocks only, without the
need to add new features or to change the current syntax of the language.

For example:

/**
 * @param float $x
 * @param float $y
 * @return float
 */
function modulus($x, $y)
{  return sqrt($x*$x + $y*$y); }

echo modulus(1,1);

can be easily statically validated and is perfectly equivalent to the
possible new syntax:

function modulus(float $x, float $y): float
{ return sqrt($x*$x + $y*$y); }

echo modulus(1,1);

Rather than changing PHP trying to (badly) imitate other languages,
the language might evolve in another completely different direction
preserving its nature of scripting language, but paying more attention
designing its features (syntax, libraries, etc.) so that static validation
and eventually compilation into an efficient binary executable code can
be performed.

Regards,
 ___ 
/_|_\  Umberto Salsi
\/_\/  www.icosaedro.it


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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Ivan Enderlin @ Hoa


Hello internal,

Thank you Andrea for this RFC.
I voted today. However, I would like to stress that my vote represents 
the opinion of Hoa's community [1] and fruux [2] (the company behind 
sabre/dav [3]).


I talked to Pierre Joye today and I was mentioning this is something we 
do since few months already and I had to spread the word here. So yes, 
my vote does not represent only 1 person but tens.


This is something we will continue since we believe that a vote must not 
represent the opinion of one person. We consider this is an opportunity 
to fill the gap between internal and PHP's community. And finally, we 
would like to encourage people with a vote to talk to anybody around 
them, at their work, at their open-source project, on IRC etc. to 
reflect the most valuable opinion.


Cheers :-).


[1] http://hoa-project.net/
[2] https://fruux.com/
[3] http://sabre.io/


On 05/02/15 21:14, Andrea Faulds wrote:

Good evening,

At long last, I’m going to put the RFC to a vote. It’s been long enough - I 
don’t think there needs to be, or will be, much further discussion.

I’d like to make sure that everyone voting understands the RFC fully. Please 
read the RFC in full: the details are important. And if  anyone has any 
questions or uncertainties, please ask them before voting. I am very happy to 
answer them.

I would urge everyone who wants type hints to vote for this RFC. It is not a 
perfect solution, but there can be no perfect solution to this issue. However, 
I think it is better than most of the alternatives suggested thus far - see the 
rationale section, and previous discussions. Crucially, this RFC would keep PHP 
a weakly-typed language, and not force either strict typing, nor weak typing, 
on anyone who does not want it. It would allow the addition of type hints to 
existing codebases. It would not create a situation where userland functions 
are strict yet internal functions are not, because the strict mode affects 
both. I’ve tested the implementation myself on my own code, and it worked well, 
providing benefits other proposals would not have given (see my previous post 
about my experiences).

Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). In 
addition to the vote on the main RFC, there is also a vote on the type aliases 
issue, and a vote to reserve the type names for future RFCs’ sake if this RFC 
fails.

The RFC can be found here, and it contains a voting widget: 
https://wiki.php.net/rfc/scalar_type_hints

Thank you for your time.

--
Andrea Faulds
http://ajf.me/








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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Feb 9, 2015 8:52 PM, Sebastian Bergmann sebast...@php.net wrote:

 Am 07.02.2015 um 02:08 schrieb Sebastian Bergmann:
  After reading your email, Nikita, I deleted my vote (it was no before).
  I will review the RFC again, with your arguments (and others) in mind
  and maybe I'll come to a different conclusion.

  I have voted (no) again.

  I still think that if we add support for scalars in type declarations
  then the corresponding check must be strict. But since that strictness
  does not align with the spirit of PHP I much rather have no support
  for scalars than one that is not strict.

Not strict? You loose me here.

Re: [PHP-DEV] [VOTE] Scalar Type Hints

2015-02-09 Thread Sebastian Bergmann

Am 09.02.2015 um 15:50 schrieb Pierre Joye:
 Not strict? You loose me here.

 I want support for scalar types in signatures. I want these type
 declarations to be strictly enforced. This is not wanted and not
 proposed by the RFC. Hence my vote.

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints