Re: [PHP-DEV] Strict typing and callback vs declare()

[Pierre Joye]

On Thu, Feb 26, 2015 at 2:10 AM, Dmitry Stogov  wrote:
> Hi Anthony,
>
> What do you think about using a user level callback for strict type checks
> instead of declare(). It won't allow changing behavior per file, but this
> has its own cons and pros.
>
>  set_strict_type_checker(function ($class_name, $function_nume, $arg_num,
> $expected_type, $value, $file, $line) {
>   ...
>   return false;
> });
> include("orig_index.php");
> ?>
>
> If callback is not set, arguments are converted according to standard
> rules, if set and returns false - fatal error or exception is thrown.
>
> The implementation should be simpler and more efficient than using
> declare().

It is too complex for what we need. The declare statement is as simple
as "use.." present as the top of the file, has to be checked just like
"use", no brainer for the users.

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] Strict typing and callback vs declare()

[Lester Caine]

On 26/02/15 11:34, Benjamin Eberlei wrote:
>> You 'll have to think about each file anyway. To add or not to add
>> > declare(strict_types=1).
>> >
> Yes, but It has only exactly one ruleset to keep in mind. With your
> approach the ruleset space is infinite. Much more complex.

Currently the rule set is already 'infinite' since many libraries will
already be checking for their own conditions and verifying they have a
valid variable to start with is the first step. The nice thing about PHP
*IS* it's flexibility in the way one is not constrained by a single core
framework and the more I look at this, the more making PHP a little more
flexible makes sense. Being able to bolt in a validation system
appropriate to the library being used makes perfect sense, but I already
see that code in the libraries I use anyway. The problem with proper
validation is that it either needs the annotation RFC to allow
definition of all the rules or access to some other data model such as
the metadata of a database. Simply saying 'int' and then blocking all
valid forms of that value is only part of the process but providing a
mechanism that CAN be optimised for the target and which can be enhanced
via that target can only be an improvement on what is proposed so far.

And the title here is wrong - this is not restricted to 'strict' it
applies to all scalar type hinting/checking.

-- 
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] Strict typing and callback vs declare()

[Dmitry Stogov]

On Thu, Feb 26, 2015 at 2:34 PM, Benjamin Eberlei 
wrote:

>
>
> On Thu, Feb 26, 2015 at 12:24 PM, Dmitry Stogov  wrote:
>
>>
>>
>> On Thu, Feb 26, 2015 at 2:09 PM, Benjamin Eberlei 
>> wrote:
>>
>>>
>>>
>>> On Thu, Feb 26, 2015 at 11:56 AM, Dmitry Stogov  wrote:
>>>


 On Thu, Feb 26, 2015 at 1:34 PM, Benjamin Eberlei 
 wrote:

>
>
> On Thu, Feb 26, 2015 at 11:10 AM, Dmitry Stogov 
> wrote:
>
>> Hi Anthony,
>>
>> What do you think about using a user level callback for strict type
>> checks
>> instead of declare(). It won't allow changing behavior per file, but
>> this
>> has its own cons and pros.
>>
>> > set_strict_type_checker(function ($class_name, $function_nume,
>> $arg_num,
>> $expected_type, $value, $file, $line) {
>>   ...
>>   return false;
>> });
>> include("orig_index.php");
>> ?>
>>
>> If callback is not set, arguments are converted according to standard
>> rules, if set and returns false - fatal error or exception is thrown.
>>
>> The implementation should be simpler and more efficient than using
>> declare().
>>
>> Thanks. Dmitry.
>>
>
> This ruins portability with third party libraries completely.
>

 Not completely, because checker may be smart enough to return "true"
 for third party files.

 >>> set_strict_type_checker(function ($class_name, $function_nume,
 $arg_num,$expected_type, $value, $file, $line) {
if (!my_own_file($filename)) {
  return true;
}
...
return false;
 });
 include("index.php");
 ?>

 And you won't have to modify each file in your project adding
 declare(strict_types=1).

>>>
>>> Yes, but you need a mechanism for each third party library to register
>>> their typechecker code and then build a generic type checker system using
>>> the right checks for the right library. This will produce really slow code
>>> considering it will trigger this on every argument.
>>>
>>
>> Only for strictly wrong arguments.
>>
>>
>>> Also i find declare(strict_types=1) is already adding another stack in
>>> my mind to think about, now having to think about every file/lirary having
>>> a different kind of validation makes it even more complicated.
>>>
>>
>> You 'll have to think about each file anyway. To add or not to add
>> declare(strict_types=1).
>>
>
> Yes, but It has only exactly one ruleset to keep in mind. With your
> approach the ruleset space is infinite. Much more complex.
>

I agree. It's more complex, but also more flexibly.
anyway, I just had an idea and posted it to discuss.


>
>
>> Callback would allow to care about strict type checks in one separate
>> place.
>> It's like to keep a screw key with every nut in your car instead of
>> keeping toolbox.
>>
>
>>
>>>
>>> Additionally it destroys the AOT compile benefit of static type hints,
>>> since you cannot compile code down to C again, because the
>>> conversion/validation is not necesarily deterministic.
>>>
>>
>> Oh god...
>> If you know the type of passed and expected argument at compile time,
>> strictness doesn't make any difference (you may only report a error at
>> compile time).
>> If you don't know type of passed or expected argument at compile time,
>> you'll have to check their equality at run-time anyway.
>>
>
> This is not my argument, just saying that what strict Types would allow
> (static analysis and AOT) is not possible when the static rules are not
> determinstic. This will lead to every pro static person to reject your
> approach. declare(strict_types=1) is about having a single, pre-determined,
> deterministic ruleset.
>

I heard it many time and many times replied with the same sentences as
above.
In my opinion, this argument is not true.
It's possible to do equally efficient static analyses and AOT with weak and
strict types.

For example:


At call site we know that $b is integer and foo() expects integer. so we
don't need to generate code for any checks



At call site we know what foo() expects integer, but don't know type of $b.
Sp we have to check it at run-time.



Here we know both types and now that they are not the same.
With strict type hints we may generate a compile-time error message or a
code for run-time error message.
With weak type hints we will generate an unconditional call to run-type
conversion function e.g. convert_string_to_long();
If we know the value at compile-time we may also perform compile-time
conversion.

Thanks. Dmitry.


>
>
>>
>> Thanks. Dmitry.
>>
>>
>>>
>>>

 Thanks. Dmitry.



>>>
>>
>

Re: [PHP-DEV] Strict typing and callback vs declare()

[Benjamin Eberlei]

On Thu, Feb 26, 2015 at 12:24 PM, Dmitry Stogov  wrote:

>
>
> On Thu, Feb 26, 2015 at 2:09 PM, Benjamin Eberlei 
> wrote:
>
>>
>>
>> On Thu, Feb 26, 2015 at 11:56 AM, Dmitry Stogov  wrote:
>>
>>>
>>>
>>> On Thu, Feb 26, 2015 at 1:34 PM, Benjamin Eberlei 
>>> wrote:
>>>


 On Thu, Feb 26, 2015 at 11:10 AM, Dmitry Stogov 
 wrote:

> Hi Anthony,
>
> What do you think about using a user level callback for strict type
> checks
> instead of declare(). It won't allow changing behavior per file, but
> this
> has its own cons and pros.
>
>  set_strict_type_checker(function ($class_name, $function_nume,
> $arg_num,
> $expected_type, $value, $file, $line) {
>   ...
>   return false;
> });
> include("orig_index.php");
> ?>
>
> If callback is not set, arguments are converted according to standard
> rules, if set and returns false - fatal error or exception is thrown.
>
> The implementation should be simpler and more efficient than using
> declare().
>
> Thanks. Dmitry.
>

 This ruins portability with third party libraries completely.

>>>
>>> Not completely, because checker may be smart enough to return "true" for
>>> third party files.
>>>
>>> >> set_strict_type_checker(function ($class_name, $function_nume,
>>> $arg_num,$expected_type, $value, $file, $line) {
>>>if (!my_own_file($filename)) {
>>>  return true;
>>>}
>>>...
>>>return false;
>>> });
>>> include("index.php");
>>> ?>
>>>
>>> And you won't have to modify each file in your project adding
>>> declare(strict_types=1).
>>>
>>
>> Yes, but you need a mechanism for each third party library to register
>> their typechecker code and then build a generic type checker system using
>> the right checks for the right library. This will produce really slow code
>> considering it will trigger this on every argument.
>>
>
> Only for strictly wrong arguments.
>
>
>> Also i find declare(strict_types=1) is already adding another stack in my
>> mind to think about, now having to think about every file/lirary having a
>> different kind of validation makes it even more complicated.
>>
>
> You 'll have to think about each file anyway. To add or not to add
> declare(strict_types=1).
>

Yes, but It has only exactly one ruleset to keep in mind. With your
approach the ruleset space is infinite. Much more complex.


> Callback would allow to care about strict type checks in one separate
> place.
> It's like to keep a screw key with every nut in your car instead of
> keeping toolbox.
>

>
>>
>> Additionally it destroys the AOT compile benefit of static type hints,
>> since you cannot compile code down to C again, because the
>> conversion/validation is not necesarily deterministic.
>>
>
> Oh god...
> If you know the type of passed and expected argument at compile time,
> strictness doesn't make any difference (you may only report a error at
> compile time).
> If you don't know type of passed or expected argument at compile time,
> you'll have to check their equality at run-time anyway.
>

This is not my argument, just saying that what strict Types would allow
(static analysis and AOT) is not possible when the static rules are not
determinstic. This will lead to every pro static person to reject your
approach. declare(strict_types=1) is about having a single, pre-determined,
deterministic ruleset.


>
> Thanks. Dmitry.
>
>
>>
>>
>>>
>>> Thanks. Dmitry.
>>>
>>>
>>>
>>
>

Re: [PHP-DEV] Strict typing and callback vs declare()

[Dmitry Stogov]

On Thu, Feb 26, 2015 at 2:09 PM, Benjamin Eberlei 
wrote:

>
>
> On Thu, Feb 26, 2015 at 11:56 AM, Dmitry Stogov  wrote:
>
>>
>>
>> On Thu, Feb 26, 2015 at 1:34 PM, Benjamin Eberlei 
>> wrote:
>>
>>>
>>>
>>> On Thu, Feb 26, 2015 at 11:10 AM, Dmitry Stogov  wrote:
>>>
 Hi Anthony,

 What do you think about using a user level callback for strict type
 checks
 instead of declare(). It won't allow changing behavior per file, but
 this
 has its own cons and pros.

 >>> set_strict_type_checker(function ($class_name, $function_nume, $arg_num,
 $expected_type, $value, $file, $line) {
   ...
   return false;
 });
 include("orig_index.php");
 ?>

 If callback is not set, arguments are converted according to standard
 rules, if set and returns false - fatal error or exception is thrown.

 The implementation should be simpler and more efficient than using
 declare().

 Thanks. Dmitry.

>>>
>>> This ruins portability with third party libraries completely.
>>>
>>
>> Not completely, because checker may be smart enough to return "true" for
>> third party files.
>>
>> > set_strict_type_checker(function ($class_name, $function_nume,
>> $arg_num,$expected_type, $value, $file, $line) {
>>if (!my_own_file($filename)) {
>>  return true;
>>}
>>...
>>return false;
>> });
>> include("index.php");
>> ?>
>>
>> And you won't have to modify each file in your project adding
>> declare(strict_types=1).
>>
>
> Yes, but you need a mechanism for each third party library to register
> their typechecker code and then build a generic type checker system using
> the right checks for the right library. This will produce really slow code
> considering it will trigger this on every argument.
>

Only for strictly wrong arguments.


> Also i find declare(strict_types=1) is already adding another stack in my
> mind to think about, now having to think about every file/lirary having a
> different kind of validation makes it even more complicated.
>

You 'll have to think about each file anyway. To add or not to add
declare(strict_types=1).
Callback would allow to care about strict type checks in one separate place.
It's like to keep a screw key with every nut in your car instead of keeping
toolbox.


>
> Additionally it destroys the AOT compile benefit of static type hints,
> since you cannot compile code down to C again, because the
> conversion/validation is not necesarily deterministic.
>

Oh god...
If you know the type of passed and expected argument at compile time,
strictness doesn't make any difference (you may only report a error at
compile time).
If you don't know type of passed or expected argument at compile time,
you'll have to check their equality at run-time anyway.

Thanks. Dmitry.


>
>
>>
>> Thanks. Dmitry.
>>
>>
>>
>

Re: [PHP-DEV] Strict typing and callback vs declare()

[Dmitry Stogov]

On Thu, Feb 26, 2015 at 1:43 PM, Joe Watkins  wrote:

> > The implementation should be simpler and more efficient than using
> declare().
>
> This can't really be correct, if a call to
>
> function mine(int $one, double $two) {
>
> }
>
> results in three function calls then that's going to cost considerably.
>

No. The callback is going to be called only when expected and passed types
are different (e.g. passing "123" to int; or 1 to bool)
It must be relatively seldom.


>
> I don't like the idea of user function being called, but don't hate the
> idea of an internal
> API that allows an extension to implement a type system.
>
> It could be much simpler, like turning zend_verify_arg_type into a pointer
> to a function like
> we did with gc function.
>
> All of this is inferior to dual mode, in my opinion.
>

Implementing, strict types in extension is an option. but I think it won't
satisfy the strict camp.
User callback is a tool that doesn't change the mainstream language
semantic, but provides a way to analyze strict type inconsistencies.

Thanks. Dmitry.




>
> Cheers
> Joe
>
> On Thu, Feb 26, 2015 at 10:34 AM, Benjamin Eberlei 
> wrote:
>
>> On Thu, Feb 26, 2015 at 11:10 AM, Dmitry Stogov  wrote:
>>
>> > Hi Anthony,
>> >
>> > What do you think about using a user level callback for strict type
>> checks
>> > instead of declare(). It won't allow changing behavior per file, but
>> this
>> > has its own cons and pros.
>> >
>> > > > set_strict_type_checker(function ($class_name, $function_nume, $arg_num,
>> > $expected_type, $value, $file, $line) {
>> >   ...
>> >   return false;
>> > });
>> > include("orig_index.php");
>> > ?>
>> >
>> > If callback is not set, arguments are converted according to standard
>> > rules, if set and returns false - fatal error or exception is thrown.
>> >
>> > The implementation should be simpler and more efficient than using
>> > declare().
>> >
>> > Thanks. Dmitry.
>> >
>>
>> This ruins portability with third party libraries completely.
>>
>
>

Re: [PHP-DEV] Strict typing and callback vs declare()

[Benjamin Eberlei]

On Thu, Feb 26, 2015 at 11:56 AM, Dmitry Stogov  wrote:

>
>
> On Thu, Feb 26, 2015 at 1:34 PM, Benjamin Eberlei 
> wrote:
>
>>
>>
>> On Thu, Feb 26, 2015 at 11:10 AM, Dmitry Stogov  wrote:
>>
>>> Hi Anthony,
>>>
>>> What do you think about using a user level callback for strict type
>>> checks
>>> instead of declare(). It won't allow changing behavior per file, but this
>>> has its own cons and pros.
>>>
>>> >> set_strict_type_checker(function ($class_name, $function_nume, $arg_num,
>>> $expected_type, $value, $file, $line) {
>>>   ...
>>>   return false;
>>> });
>>> include("orig_index.php");
>>> ?>
>>>
>>> If callback is not set, arguments are converted according to standard
>>> rules, if set and returns false - fatal error or exception is thrown.
>>>
>>> The implementation should be simpler and more efficient than using
>>> declare().
>>>
>>> Thanks. Dmitry.
>>>
>>
>> This ruins portability with third party libraries completely.
>>
>
> Not completely, because checker may be smart enough to return "true" for
> third party files.
>
>  set_strict_type_checker(function ($class_name, $function_nume,
> $arg_num,$expected_type, $value, $file, $line) {
>if (!my_own_file($filename)) {
>  return true;
>}
>...
>return false;
> });
> include("index.php");
> ?>
>
> And you won't have to modify each file in your project adding
> declare(strict_types=1).
>

Yes, but you need a mechanism for each third party library to register
their typechecker code and then build a generic type checker system using
the right checks for the right library. This will produce really slow code
considering it will trigger this on every argument.

Also i find declare(strict_types=1) is already adding another stack in my
mind to think about, now having to think about every file/lirary having a
different kind of validation makes it even more complicated.

Additionally it destroys the AOT compile benefit of static type hints,
since you cannot compile code down to C again, because the
conversion/validation is not necesarily deterministic.


>
> Thanks. Dmitry.
>
>
>

Re: [PHP-DEV] Strict typing and callback vs declare()

[Dmitry Stogov]

On Thu, Feb 26, 2015 at 1:34 PM, Benjamin Eberlei 
wrote:

>
>
> On Thu, Feb 26, 2015 at 11:10 AM, Dmitry Stogov  wrote:
>
>> Hi Anthony,
>>
>> What do you think about using a user level callback for strict type checks
>> instead of declare(). It won't allow changing behavior per file, but this
>> has its own cons and pros.
>>
>> > set_strict_type_checker(function ($class_name, $function_nume, $arg_num,
>> $expected_type, $value, $file, $line) {
>>   ...
>>   return false;
>> });
>> include("orig_index.php");
>> ?>
>>
>> If callback is not set, arguments are converted according to standard
>> rules, if set and returns false - fatal error or exception is thrown.
>>
>> The implementation should be simpler and more efficient than using
>> declare().
>>
>> Thanks. Dmitry.
>>
>
> This ruins portability with third party libraries completely.
>

Not completely, because checker may be smart enough to return "true" for
third party files.



And you won't have to modify each file in your project adding
declare(strict_types=1).

Thanks. Dmitry.

Re: [PHP-DEV] Strict typing and callback vs declare()

[Joe Watkins]

> The implementation should be simpler and more efficient than using
declare().

This can't really be correct, if a call to

function mine(int $one, double $two) {

}

results in three function calls then that's going to cost considerably.

I don't like the idea of user function being called, but don't hate the
idea of an internal
API that allows an extension to implement a type system.

It could be much simpler, like turning zend_verify_arg_type into a pointer
to a function like
we did with gc function.

All of this is inferior to dual mode, in my opinion.

Cheers
Joe

On Thu, Feb 26, 2015 at 10:34 AM, Benjamin Eberlei 
wrote:

> On Thu, Feb 26, 2015 at 11:10 AM, Dmitry Stogov  wrote:
>
> > Hi Anthony,
> >
> > What do you think about using a user level callback for strict type
> checks
> > instead of declare(). It won't allow changing behavior per file, but this
> > has its own cons and pros.
> >
> >  > set_strict_type_checker(function ($class_name, $function_nume, $arg_num,
> > $expected_type, $value, $file, $line) {
> >   ...
> >   return false;
> > });
> > include("orig_index.php");
> > ?>
> >
> > If callback is not set, arguments are converted according to standard
> > rules, if set and returns false - fatal error or exception is thrown.
> >
> > The implementation should be simpler and more efficient than using
> > declare().
> >
> > Thanks. Dmitry.
> >
>
> This ruins portability with third party libraries completely.
>

Re: [PHP-DEV] Strict typing and callback vs declare()

[Benjamin Eberlei]

On Thu, Feb 26, 2015 at 11:10 AM, Dmitry Stogov  wrote:

> Hi Anthony,
>
> What do you think about using a user level callback for strict type checks
> instead of declare(). It won't allow changing behavior per file, but this
> has its own cons and pros.
>
>  set_strict_type_checker(function ($class_name, $function_nume, $arg_num,
> $expected_type, $value, $file, $line) {
>   ...
>   return false;
> });
> include("orig_index.php");
> ?>
>
> If callback is not set, arguments are converted according to standard
> rules, if set and returns false - fatal error or exception is thrown.
>
> The implementation should be simpler and more efficient than using
> declare().
>
> Thanks. Dmitry.
>

This ruins portability with third party libraries completely.

[PHP-DEV] Strict typing and callback vs declare()

[Dmitry Stogov]

Hi Anthony,

What do you think about using a user level callback for strict type checks
instead of declare(). It won't allow changing behavior per file, but this
has its own cons and pros.



If callback is not set, arguments are converted according to standard
rules, if set and returns false - fatal error or exception is thrown.

The implementation should be simpler and more efficient than using
declare().

Thanks. Dmitry.

Re: [PHP-DEV] Strict typing

[Zeev Suraski]

At 10:57 12/08/2010, Daniel Egeberg wrote:

> Everyone who opposes strict typing on grounds that it's an alien
> feature to PHP(*) doesn't see any advantages in this suggestion

Perhaps if you stopped pretending to know everybody's opinion


Suggest you re-read what I said, you didn't seem to understand it.

Zeev


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

Re: [PHP-DEV] Strict typing

[Daniel Egeberg]

2010/8/12 Zeev Suraski :
> At 04:02 12/08/2010, Josh Davis wrote:
>>
>> What would be interesting to see is what people think of Derick's
>> latest proposal allowing both the strict typechecking and the more
>> sensible "weak typing"
>
> Everyone who opposes strict typing on grounds that it's an alien
> feature to PHP(*) doesn't see any advantages in this suggestion, as
> everything that's bad in strict typing remains on the table.  If there were
> only two options left on earth, strict typing and strict+auto-conversion,
> I'd vote for going with just strict.

Who appointed you the official anti-strict ambassador? If there really
are so many people who think it's the worst idea since the dawn of
mankind, it will be revealed when it's inevitably time for a vote.

Perhaps if you stopped pretending to know everybody's opinion, it
would be easier finding a consensus. Unless someone expressed their
opinion, it is *unknown*. Stick to expressing your *own* opinion.

I don't see any reason why we can't provide "smartcast" for when the
API provider cares about the value *and* "strict typing" for when the
API provider cares about the data type.

Providing both options instead of only strict is entirely different.
If there is only strict, then that is the only option the PHP users
have if they want type hinting (yes, incorrect term, yadda yadda). If
both are available, people still have the option to use strict in the
specific use cases where they need it, but use smartcast otherwise.

If you don't like "function foo(int $i)" (strict) vs. "function
foo((int) $i)" (smarcast), it could just as well be "function foo(int
$i)" (smartcast) and "function foo(+int $i)" (strict, other char than
"plus" could possibly be used). This has two benefits to the former
syntax choices:
1) The smartcast syntax would be consistent with how the APIs are
documented in PHP's documentation, so the syntax in PHP would not
conflict.
2) "+int" isn't used anywhere, so it's obvious that it's something
different and it's easy to see in API documentations, auto-completion,
etc.

-- 
Daniel Egeberg

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

Re: [PHP-DEV] Strict typing

[Victor Bolshov]

> If there were
> only two options left on earth, strict typing and strict+auto-conversion,
> I'd vote for going with just strict.

Completely agree. I'm against strict approach, but I would prefer
strict to "strict+auto-conversion".

I see a sense in weak typehints. I see a lesser sense in strict. And I
see lesser lesser sense in combining the two.

And, for the record: I vote for keeping the status quo regarding
typehints. If this feature causes so much debate, why not leave it
until better times and concentrate on other ones?

I hope this comment will be of interest in the context of "What would
be interesting to see is what people think of Derick's latest proposal
allowing both the strict typechecking and the more sensible "weak
typing". I am a PHP end-user so I am one of the people, too.

2010/8/12 Zeev Suraski :
> At 04:02 12/08/2010, Josh Davis wrote:
>>
>> What would be interesting to see is what people think of Derick's
>> latest proposal allowing both the strict typechecking and the more
>> sensible "weak typing"
>
> There's nothing new about it, it's been on the table for around half a year
> now.  Everyone who opposes strict typing on grounds that it's an alien
> feature to PHP(*) doesn't see any advantages in this suggestion, as
> everything that's bad in strict typing remains on the table.  If there were
> only two options left on earth, strict typing and strict+auto-conversion,
> I'd vote for going with just strict.
>
> Zeev
>
> (*)
> http://wiki.php.net/rfc/typecheckingstrictandweak
> - 'Why is strict type checking problematic'
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
С уважением,
Виктор

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

Re: [PHP-DEV] Strict typing

[Zeev Suraski]

At 04:02 12/08/2010, Josh Davis wrote:

What would be interesting to see is what people think of Derick's
latest proposal allowing both the strict typechecking and the more
sensible "weak typing"


There's nothing new about it, it's been on the table for around half 
a year now.  Everyone who opposes strict typing on grounds that it's 
an alien feature to PHP(*) doesn't see any advantages in this 
suggestion, as everything that's bad in strict typing remains on the 
table.  If there were only two options left on earth, strict typing 
and strict+auto-conversion, I'd vote for going with just strict.


Zeev

(*) 
http://wiki.php.net/rfc/typecheckingstrictandweak 
- 'Why is strict type checking problematic'




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

Re: [PHP-DEV] Strict typing

[David Soria Parra]

On 2010-08-11, Pierre Joye  wrote:
> On Thu, Aug 12, 2010 at 12:11 AM, Zeev Suraski  wrote:
> To think that one guy considered that he is allowed to decide to fire
> a 5.4, announce it, all that without a single discussion in the public
> list is really bad. Even worst is that nobody actually even tries to
> say that it is not acceptable. And it happened more than once already.
I agree. During 5.3 development we made a step into the right directon of
having a slightly more formal release process with more transparency,
that includes decisions of active developers and not a decision of
one guy. Ongoing discussions offlist do not help here. We should try
to focus on the way we want to do the release and not fall back into
"who-shot-first-wins".

Although I think it's good to have a 5.4 alpha soon, we first should try
to clarify the way we want to release it (from trunk, from 5.4 branch
with feature merges, RMs, strict typing, etc).

- David

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

Re: [PHP-DEV] Strict typing

[Josh Davis]

2010/8/12 Johannes Schlüter :
> Yes, my blog posting reflects my opinion and therefore is manipulative

Indeed. Depending where you'll look, you'll find big communities that
have no clue about or no need for type hinting/checking/casting, some
communities where "strict" typing is heresy, others where "weak"
typing is seen as too lax, etc... All I've read on that topic was from
small communities with targeted audiences, which produce some very
polarized opinions.

What would be interesting to see is what people think of Derick's
latest proposal allowing both the strict typechecking and the more
sensible "weak typing" (which I call smartcasting because you know, it
does typecast stuff and prefixing it with "smart" make it sound better
IMO.) It would weed out most of the knee-jerk reactions and focus on
whether it solves problems or overly complicates things or makes them
confusing.

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

Re: [PHP-DEV] Strict typing

[Johannes Schlüter]

On Thu, 2010-08-12 at 01:21 +0200, Josh Davis wrote:
> Either way, let me skew your numbers a bit by using Ilia's blog post
> from last year [1] and earlier this year [2]. If that was my only
> benchmark I'd say that there is unanimous support for the
> implementation in current trunk. I guess it shows that different
> communities produce different opinions.
> 
> [1] http://ilia.ws/archives/205-Type-hinting-for-PHP-5.3.html
> [2] http://ilia.ws/archives/217-Scalar-Type-Hints-are-Here!.html

Now compare it to the comments on my blog:
http://schlueters.de/blog/archives/139-Scalar-type-hints-in-PHP-trunk.html

Yes, my blog posting reflects my opinion and therefore is manipulative
by focusing on the negative effects. Both blog postings reach their
audience via the same channels so they reach more or less the same
people. But well, Ilia's audience only got the positive effects, mine
got only the negative effects of the patch. To really judge it you need
some time to think through it and probably even play with the patch
(which I did, the blog posting only shows small parts, I'd have other
examples where weird things happened, but they were too complex for a
simple blog post) what "nobody" commenting in blogs does.

But then even if there are "many" users out there: It is still this
group here which has to maintain it. And why should I maintain anything
I consider stupid and wrong for free for strangers?

johannes



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

Re: [PHP-DEV] Strict typing

[Josh Davis]

On 12 August 2010 00:11, Zeev Suraski  wrote:
> I'm not sure how long you've been on internals, but I'm not sure there's any
> precedence to such strong and diverse opposition to a feature - amongst both
> core developers, original authors and the community at large.

I don't know, I remember some pretty strong words used against goto :)

As for the community at large... I don't remember seeing a "strong and
diverse opposition" to having both typechecking and smartcasting in
PHP. If you have any links, perhaps that will help me grasp how strong
and diverse the opposition is.

Either way, let me skew your numbers a bit by using Ilia's blog post
from last year [1] and earlier this year [2]. If that was my only
benchmark I'd say that there is unanimous support for the
implementation in current trunk. I guess it shows that different
communities produce different opinions.

[1] http://ilia.ws/archives/205-Type-hinting-for-PHP-5.3.html
[2] http://ilia.ws/archives/217-Scalar-Type-Hints-are-Here!.html

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

Re: [PHP-DEV] Strict typing

[Pierre Joye]

On Thu, Aug 12, 2010 at 12:11 AM, Zeev Suraski  wrote:
> At 00:58 12/08/2010, Josh Davis wrote:
>>
>> > Now that strict typing is pretty clearly off the table - how would those
>>
>> Wait, what? Clearly off the table?
>
> Yes, clearly off the table.
>
> I'm not sure how long you've been on internals, but I'm not sure there's any
> precedence to such strong and diverse opposition to a feature - amongst both
> core developers, original authors and the community at large.  At least I
> can't remember one in the last 13 years (it's been a long time though, maybe
> I forgot).

Zeev, I think you underestimate the problem. The hinting (or whatever
is the name of this pointless thing) is the least of the problems we
have right now.

To think that one guy considered that he is allowed to decide to fire
a 5.4, announce it, all that without a single discussion in the public
list is really bad. Even worst is that nobody actually even tries to
say that it is not acceptable. And it happened more than once already.

Yes, I sound and I am negative. Because it is a huge step backward for
the PHP project. And I seriously think that it won't end well if we
continue to act like that.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] Strict typing

[Zeev Suraski]

Daniel,

In order to radically change PHP you need very strong consensus.  If 
you don't have it, the status quo holds.


Strict typing doesn't have anything remotely close to strong 
consensus.  It doesn't really matter if a lot of people support it - 
there are also plenty of people who oppose it.  Among them you have 
the original authors of the language, many core developers, and 
countless community members.  That seals the deal - the status quo 
cannot change when so many oppose it - even if many support it.


You should definitely take a closer look if you think that there's 
only a small group of people who oppose it.  Recommended reading are 
this list and Johannes's blog.


Zeev


At 01:05 12/08/2010, Daniel Egeberg wrote:

On Wed, Aug 11, 2010 at 23:26, Zeev Suraski  wrote:
> Now that strict typing is pretty clearly off the table [...]

Did I miss a vote or something? The only thing I've seen is the same
small group of people that has been fighting for the last few months.

Your reasoning seems to be "there are people who complained, so it's
out", but "there are plenty of people who haven't complained, so it's
in" is an equally justifiable position to take. Obviously people
aren't going to sends loads of "I think everything is perfectly
fine"-emails.

PS: Can I get a list of the PHP axioms? Seeing as that's apparently
how things are decided, it would be nice if people won't have to waste
your precious time making obnoxious feature requests that are
*clearly* against the PHP axioms.

--
Daniel Egeberg



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

Re: [PHP-DEV] Strict typing

[Zeev Suraski]

At 00:58 12/08/2010, Josh Davis wrote:

> Now that strict typing is pretty clearly off the table - how would those

Wait, what? Clearly off the table?


Yes, clearly off the table.

I'm not sure how long you've been on internals, but I'm not sure 
there's any precedence to such strong and diverse opposition to a 
feature - amongst both core developers, original authors and the 
community at large.  At least I can't remember one in the last 13 
years (it's been a long time though, maybe I forgot).


It's completely independent from any other idea we might have in 
mind.  Strict typing will not happen in PHP.


Zeev


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

Re: [PHP-DEV] Strict typing

[Daniel Egeberg]

On Wed, Aug 11, 2010 at 23:26, Zeev Suraski  wrote:
> Now that strict typing is pretty clearly off the table [...]

Did I miss a vote or something? The only thing I've seen is the same
small group of people that has been fighting for the last few months.

Your reasoning seems to be "there are people who complained, so it's
out", but "there are plenty of people who haven't complained, so it's
in" is an equally justifiable position to take. Obviously people
aren't going to sends loads of "I think everything is perfectly
fine"-emails.

PS: Can I get a list of the PHP axioms? Seeing as that's apparently
how things are decided, it would be nice if people won't have to waste
your precious time making obnoxious feature requests that are
*clearly* against the PHP axioms.

-- 
Daniel Egeberg

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

Re: [PHP-DEV] Strict typing

[Josh Davis]

On 11 August 2010 23:26, Zeev Suraski  wrote:
> matter how much I try to explain - it won't help - we probably see things
> too differently for us to ever agree on it.  Let's end it by saying that a
> great deal of people here think it's horrible to introduce strict typing to
> PHP period.

Sure, as long as you don't present your opinion as a fact and we
acknowledge that a lot of people also think that type checking is
desirable. (as evidenced by the various "strict typing" patches we
have seen) I would never try to change your opinions.

> The opposition to strict typing was that it's 'evil', and we mustn't
> introduce it into PHP.

Yes, and we know how overused the argument "X is evil" is.

> The opposition to auto-converting type hints was that strict typing is
> supposedly better.

I think I read some mails to that effect the last time that discussion
ran its course.

> Now that strict typing is pretty clearly off the table - how would those

Wait, what? Clearly off the table?

Derick has restarted the discussion 23 hours ago and judging from his
last mail he his still writing a new patch and you're already calling
it "off the table" ? =\

> that supported it vote between doing nothing at all and 'settling' for
> auto-converting type hints?  That's the real question on the table now.

The only question I have read from a developer about what kind of type
hints would satisfy the community was from Derick, 23 hours ago and
the question was "[supporting both kinds of typing] [s]hould make
everybody happy (enough), right?" - So right now I would say that it
is literally the only question being asked.

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

Re: [PHP-DEV] Strict typing

[Zeev Suraski]

At 00:26 12/08/2010, Zeev Suraski wrote:
Moving forward with both is certainly not the only option, I'd say 
(given the paragraph above) that it's not an option at all.  At the 
very least, there's one other option which is doing nothing.  And 
that's assuming we can't reach widespread consensus that 
auto-converting type hints are bad.


s/bad/good


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

Re: [PHP-DEV] Strict typing

[Zeev Suraski]

At 23:59 11/08/2010, Josh Davis wrote:

Not sure what kind of impact we're talking about here. Currently,
there's no scalar type hinting and there will never be a consensus
around strict XOR weak. Having an implementation that allows both
while reusing a familiar syntax (parentheses as a way typecast) looks
like the best (and perhaps only) way to move on.


Josh,

No disrespect, but I can't explain why it's bad to have both 
implementations any better than I already did.  If you don't see it, 
chances are that no matter how much I try to explain - it won't help 
- we probably see things too differently for us to ever agree on 
it.  Let's end it by saying that a great deal of people here think 
it's horrible to introduce strict typing to PHP period.  Whether we 
also add anything else at the same time doesn't change that one bit.


Moving forward with both is certainly not the only option, I'd say 
(given the paragraph above) that it's not an option at all.  At the 
very least, there's one other option which is doing nothing.  And 
that's assuming we can't reach widespread consensus that 
auto-converting type hints are bad.


The opposition to strict typing was that it's 'evil', and we mustn't 
introduce it into PHP.
The opposition to auto-converting type hints was that strict typing 
is supposedly better.


Now that strict typing is pretty clearly off the table - how would 
those that supported it vote between doing nothing at all and 
'settling' for auto-converting type hints?  That's the real question 
on the table now.


For the record, I'm fine with both options, although personally I'd 
go for the latter.


Zeev 



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

Re: [PHP-DEV] Strict typing

[Josh Davis]

On 11 August 2010 21:59, Zeev Suraski  wrote:
> Consensus about what?  About two similar features with slightly different
> syntax being a bad thing?  I don't think we need consensus for that.  That's
> not up for discussion.  It's an axiom for PHP.

Of course it depends on your definition of "similar features." One
feature checks the type of an argument, the other checks the value of
an argument and casts it to another type if necessary. I see it as
serving two different applications, just like == and === are meant for
different things despite being two similar operators.

> See above.  It would do everyone good if they don't just think about
> themselves and whether they're fine or not with a given feature, but about
> the impact it would have on the userbase at large.

Not sure what kind of impact we're talking about here. Currently,
there's no scalar type hinting and there will never be a consensus
around strict XOR weak. Having an implementation that allows both
while reusing a familiar syntax (parentheses as a way typecast) looks
like the best (and perhaps only) way to move on.

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

Re: [PHP-DEV] Strict typing

[Guillaume Rossolini]

On Wed, Aug 11, 2010 at 9:29 PM, Josh Davis  wrote:
>
>
> If I'm using type checking as a sanity check then it doesn't work as
> soon as it accepts "1" for an int. The described "weak typehinting" is
> good if you're looking for a way to validate input. However, it does
> not work if you're trying to make sure that Stuff Is Going As
> Planned(tm). For example, consider a protected method
> getTheNextNTokens(int $n) which is part of some tokenizer or
> something. It is a protected method and you never write
> getTheNextNTokens("2") so if it ever receives something that is not an
> integer, it means that there's a subtle bug somewhere. In that case,
> "strict typehinting" buys you peace of mind.
>
>
Hi

Thank you for the use case, we need more of them.

However in this example, what kind of application wouldn't make this $n
parameter configurable (ini file, XML file, user preference from a database
etc.) at some point? Then you would be back to square one, meaning you would
have to cast your database output so that your strict API accepts the
natural evolution of your app. Or you would have to get rid of the strict
check and replace it with a userland checking and validation chain (which
you should do anyway), at which point you wouldn't need or want type
checking but you would be glad to have type casting. In PHP, every single
value potentially comes from a kind of stream (file, HTTP or otherwise),
there is no such thing as a fully internal configurable value that I can
think of. Or is there? If there is, why would it need type checking at all?

Type checking or type casting won't save you much trouble since, as you said
yourself, in both cases you need to properly validate any data before doing
anything funny. However, with type checking you don't get any actual benefit
that I can see, while with type casting you can do other things relying on
the cast to properly format some of your data for you. If you have a
validation chain, why do you need type checking? If you don't validate your
data, type checking won't help. It would give a false sense of security,
nothing more. In edge cases like you described, type checking leaves you
with a broken app (fatal error / white page), while with type casting you'd
have a kind of recoverable error that you could... recover from. In neither
case your users care what happens internally, so IMO they should not be
taken hostage of your design mistakes or your choice of libraries. And yes,
if your app fails a typecheck, it means it fails with a fatal error and your
users get frustrated.

One use case I can think of is during testing, but in this case you can
already do the same with a testing framework. Just declare the types in the
comments and have the framework use those, but don't let them stand in the
way the app actually works. Using strict type checks would be like hard
coding your debugging breakpoints, would it not?

Best regards,

--
Guillaume Rossolini

Re: [PHP-DEV] Strict typing

[Zeev Suraski]

At 22:54 11/08/2010, Josh Davis wrote:

On 11 August 2010 20:40, Zeev Suraski  wrote:
> Josh,
>
> This too (having both options) was debated many times.  Read the archives.

I have already read the archives thank you very much. I'm sure you
have too and you remember that there's never been a consensus. I'm
sure that Derick remembers them as well, yet he restarted the
discussion instead of letting it rot in limbo.


Consensus about what?  About two similar features with slightly 
different syntax being a bad thing?  I don't think we need consensus 
for that.  That's not up for discussion.  It's an axiom for PHP.



> Short version?  Strict typing is evil.  The only thing that's even worse?
>  Adding both Strict typing and something else.  Why?  You get everything
> that's bad about strict typing, combined with the added confusion of two
> ways of doing similar things.

That's your opinion and I beg to differ. I find that having both type
of "typehints" is having the best of both world at almost no cost. I
am no more confused by the use of parentheses in a method's
declaration than I am by their use in a if construct, in a new Foo()
instantiation or used anywhere else in PHP.

Knowing the difference between different constructs is part of
learning a language (just like learning that $a==$b and $a===b are
different) and I don't see librairies meant to be used by beginners
use strict typechecking anyway. In all likelihood, it will only be
used by users and frameworks that want the greatest degree of control
over their own code, possibly using strict typechecking for internal
stuff and "weak" typehinting (smartcasting!) for public APIs.


See above.  It would do everyone good if they don't just think about 
themselves and whether they're fine or not with a given feature, but 
about the impact it would have on the userbase at large.


Zeev


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

Re: [PHP-DEV] Strict typing

[Josh Davis]

On 11 August 2010 20:40, Zeev Suraski  wrote:
> Josh,
>
> This too (having both options) was debated many times.  Read the archives.

I have already read the archives thank you very much. I'm sure you
have too and you remember that there's never been a consensus. I'm
sure that Derick remembers them as well, yet he restarted the
discussion instead of letting it rot in limbo.

> Short version?  Strict typing is evil.  The only thing that's even worse?
>  Adding both Strict typing and something else.  Why?  You get everything
> that's bad about strict typing, combined with the added confusion of two
> ways of doing similar things.

That's your opinion and I beg to differ. I find that having both type
of "typehints" is having the best of both world at almost no cost. I
am no more confused by the use of parentheses in a method's
declaration than I am by their use in a if construct, in a new Foo()
instantiation or used anywhere else in PHP.

Knowing the difference between different constructs is part of
learning a language (just like learning that $a==$b and $a===b are
different) and I don't see librairies meant to be used by beginners
use strict typechecking anyway. In all likelihood, it will only be
used by users and frameworks that want the greatest degree of control
over their own code, possibly using strict typechecking for internal
stuff and "weak" typehinting (smartcasting!) for public APIs.

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

Re: [PHP-DEV] Strict typing

[Josh Davis]

On 11 August 2010 19:11, Alexey Zakhlestin  wrote:
> Did you read second RFC? The one which is about "so called" weak typehinting.
> Stas (and a lot of people on this list) prefer it.
> http://wiki.php.net/rfc/typecheckingstrictandweak

Yes of course, but reposting that link is a good idea. :)

> If you did, can you tell if there is some case, when it doesn't work for you?

If I'm using type checking as a sanity check then it doesn't work as
soon as it accepts "1" for an int. The described "weak typehinting" is
good if you're looking for a way to validate input. However, it does
not work if you're trying to make sure that Stuff Is Going As
Planned(tm). For example, consider a protected method
getTheNextNTokens(int $n) which is part of some tokenizer or
something. It is a protected method and you never write
getTheNextNTokens("2") so if it ever receives something that is not an
integer, it means that there's a subtle bug somewhere. In that case,
"strict typehinting" buys you peace of mind.

If your function lives in a controlled environment (e.g. private
methods, or because your specifications require to use the filter
extension to validate input) then checking for the type of a variable
offers more protection against the unexpected than checking for its
contents. Of course, it's not an absolute protection, just like making
a method private does not guarantee that a user [of your code] won't
extend it to make it public or use ReflectionMethod to make it
accessible. It's just another way to defend against the unexpected.

I hope it answers your question :)

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

Re: [PHP-DEV] Strict typing

[Zeev Suraski]

Josh,

This too (having both options) was debated many times.  Read the archives.

Short version?  Strict typing is evil.  The only thing that's even 
worse?  Adding both Strict typing and something else.  Why?  You get 
everything that's bad about strict typing, combined with the added 
confusion of two ways of doing similar things.


Zeev


At 21:31 11/08/2010, Josh Davis wrote:

On 11 August 2010 19:20, Stas Malyshev  wrote:
> I'm against it on sanity and logic grounds. I explained the 
reasons (for the

> Nth time) above. If you still can't comprehend that there's logic behind
> what I am saying and call it "ideology" - well, I guess there's a limit of
> what one can explain.

I perfectly understand that there are reasons behind wanting the more
relaxed "smartcasting" to be the only option but please go ahead and
be condescending if you want. There is logic behind what you're
saying: your logic. It's not a universal logic though, as evidenced by
the lack of consensus.

My point is this: Derick's proposal (which started this thread before
it got forked somehow) was to allow everybody to have it their way.
You are fighting tooth and nail to prevent that from happening,
choosing instead to impose your logic and your definition of what is
sound to the users. I call that ideology. My own ideology is to leave
that choice to the users if it doesn't incur a high cost. That way, my
ideology is more compatible with others'.

Offering both typechecking and smartcasting is compatible with both
groups of users, which, btw, do overlap to some extent; if the feature
was available I'd use typechecking for internal functions and
smartcasting for most of the public stuff, depending on what rules it
follows.

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



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

Re: [PHP-DEV] Strict typing

[Josh Davis]

On 11 August 2010 19:20, Stas Malyshev  wrote:
> I'm against it on sanity and logic grounds. I explained the reasons (for the
> Nth time) above. If you still can't comprehend that there's logic behind
> what I am saying and call it "ideology" - well, I guess there's a limit of
> what one can explain.

I perfectly understand that there are reasons behind wanting the more
relaxed "smartcasting" to be the only option but please go ahead and
be condescending if you want. There is logic behind what you're
saying: your logic. It's not a universal logic though, as evidenced by
the lack of consensus.

My point is this: Derick's proposal (which started this thread before
it got forked somehow) was to allow everybody to have it their way.
You are fighting tooth and nail to prevent that from happening,
choosing instead to impose your logic and your definition of what is
sound to the users. I call that ideology. My own ideology is to leave
that choice to the users if it doesn't incur a high cost. That way, my
ideology is more compatible with others'.

Offering both typechecking and smartcasting is compatible with both
groups of users, which, btw, do overlap to some extent; if the feature
was available I'd use typechecking for internal functions and
smartcasting for most of the public stuff, depending on what rules it
follows.

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

Re: [PHP-DEV] Strict typing

[Stas Malyshev]

Hi!


Yeah, hmm, no, and it is disingenuous of you to equate type hints to
PHP becoming statically typed. I'm sure that some people would love to


See? That's exactly why I am so opposed to calling it "type hints". 
Because if you called it proper name - strict typing, you'd say "it is 
disingenuous of you to equate strict typing to PHP becoming statically 
typed" and it'd make you think that maybe it doesn't sound good.



have optional static typing in parts of their code, but I like being
able to use my vars freely when I need to. Being able to enforce what


That only leads to very bad coding practices. If you have strictly typed 
parameter "int $foo", any data path that leads to $foo should be 
verified to always produce "int" - otherwise your code blows up at 
runtime (no compile-time checks, remember?). That can be achieved in one 
of two ways:

1. Having convert/check before each call to the function
2. Having variables and parameters to upstream functions typed

1 is insanely-ugly code, 2 is static typing. You choose.


PHP being dynamically typed shouldn't be an argument to prevent people
from enforcing method signatures. You're saying that PHP users should
have no control over what variable types are passed to their
functions.


No, I'm not saying that. I'm saying, see above, that there are 
consequences to strictly typed parameters. You can, of course, choose 
third way and have half-assed implementation, but that would prove to 
work badly very quickly. As soon as you discover it, you'd ask for typed 
variables and typed returns and typed properties, etc. etc. Enter static 
typing. The fact that you won't use it for every variable doesn't matter.



More seriously, one of PHP's most popular quality is that it is
flexible. When I started using PHP, I would never initialize variables


Flexible doesn't mean "changes at my every whim without regard for 
consequences". This change is bad. It should be rolled back.



back then no one told me "oh you want warnings on initialized
variables? You should use C++ then! Haha!" PHP was flexible enough to


Unitialized vars notice is one of the great mistakes in PHP. The amount 
of ugly boilerplate code that it brings along is mind-boggling. You 
can't just say if($_REQUEST['blah'] == 'blah') do_stuff(); - you have to 
put isset() there or you get a very costly, annoying and completely 
useless error message. It was a mistake to create it. But that's another 
discussion, not for now.



to their functions what they want. And you're against that on...
ideological grounds?


I'm against it on sanity and logic grounds. I explained the reasons (for 
the Nth time) above. If you still can't comprehend that there's logic 
behind what I am saying and call it "ideology" - well, I guess there's a 
limit of what one can explain.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] Strict typing

[Alexey Zakhlestin]

On Wed, Aug 11, 2010 at 8:56 PM, Josh Davis  wrote:
> On 11 August 2010 08:23, Stas Malyshev  wrote:
>
>>> I very much can, it's just not my intention. I want to be able to use
>>> type hinting/type checking as a sanity check. If I write a method
>>> whose signature is foo(int $n) I signal my intention to only accept
>>
>> Then you should use statically typed language.
>
> Yeah, hmm, no, and it is disingenuous of you to equate type hints to
> PHP becoming statically typed. I'm sure that some people would love to
> have optional static typing in parts of their code, but I like being
> able to use my vars freely when I need to. Being able to enforce what
> type of arguments can be passed to my functions and methods would
> allow me to cut down on my parameters validation. Similarly, I like
> using protected methods to prevent users [developers using the code]
> from misusing them or protected properties to prevent users from
> inadvertently modifying them, so that I don't have to worry about the
> application being in an inconsistent state.
>
> PHP being dynamically typed shouldn't be an argument to prevent people
> from enforcing method signatures. You're saying that PHP users should
> have no control over what variable types are passed to their
> functions.

Did you read second RFC? The one which is about "so called" weak typehinting.
Stas (and a lot of people on this list) prefer it.
http://wiki.php.net/rfc/typecheckingstrictandweak

If you did, can you tell if there is some case, when it doesn't work for you?

The idea is simple:
1) if variable type matches — variable is passed to function
2) if variable can be safely converted to the type, which matches —
variable is converted and passed to the function (you still get
variable of desired type)
3) if variable can not be safely converted — error is raised

error is E_STRICT or E_FATAL (not decided yet). anyway, you can handle
it as fatal in error-handler if you need to

this way you (library developer) get your desired data-types for input
and users get freedom to pass numeric strings instead of numbers
good for everyone

-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/

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

Re: [PHP-DEV] Strict typing

[Josh Davis]

On 11 August 2010 08:23, Stas Malyshev  wrote:

>> I very much can, it's just not my intention. I want to be able to use
>> type hinting/type checking as a sanity check. If I write a method
>> whose signature is foo(int $n) I signal my intention to only accept
>
> Then you should use statically typed language.

Yeah, hmm, no, and it is disingenuous of you to equate type hints to
PHP becoming statically typed. I'm sure that some people would love to
have optional static typing in parts of their code, but I like being
able to use my vars freely when I need to. Being able to enforce what
type of arguments can be passed to my functions and methods would
allow me to cut down on my parameters validation. Similarly, I like
using protected methods to prevent users [developers using the code]
from misusing them or protected properties to prevent users from
inadvertently modifying them, so that I don't have to worry about the
application being in an inconsistent state.

PHP being dynamically typed shouldn't be an argument to prevent people
from enforcing method signatures. You're saying that PHP users should
have no control over what variable types are passed to their
functions.

>> If PHP was meant to prevent programmers from controlling the type of
>> their variables then I'm afraid there's been a misunderstanding and
>
> PHP and dynamic languages in general are not preventing people from knowing
> the types of variables, they however remove a number of annoyances that come
> with static types. You want to bring all those back

You should note that I said "controlling" not "knowing." I don't know
what that second bit about static typing is about and why you're
accusing me of wanting to force "annoyances" on everybody else. All I
have said is I'd like to be able to control what variable types are
passed to my functions and apparently you are very much against that.

> If you want strict typing ("control the type of my variables") I'm afraid
> you're using not only wrong language but wrong paradigm. You should be using
> statically typed language. Try C# or Java or Scala or something like that.

If you want a typeless language I'm afraid you're using the wrong
language. Try ColdFusion. (is ColdFusion really typeless? I don't
remember. Sorry if I'm not as good at making snarky remarks)

More seriously, one of PHP's most popular quality is that it is
flexible. When I started using PHP, I would never initialize variables
and I would always assume that somehow someway anything passed in the
URL would become a variable. It worked great, except in some cases
where it bit me in my behind. So I bumped up the error_reporting level
and started paying attention to uninitialized variables. Fortunately,
back then no one told me "oh you want warnings on initialized
variables? You should use C++ then! Haha!" PHP was flexible enough to
allow both the absolute beginner and the slightly less beginner to
have what they want.

Today, we are faced with the possibility of giving both people who
want control over what variable types are passed to their functions
and people who want the engine to determine what values can be passed
to their functions what they want. And you're against that on...
ideological grounds?

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

Re: [PHP-DEV] Strict typing

[Chad Fulton]

> anyway .. for the love of god, could be please stop arguing in circles, 
> nothing .. really nothing that people brought forth pro/con any approach in 
> regards to type checking/hinting whatever hasn't been mentioned on this list 
> multiple times.

+1

> please please please please .. read the RFC's on the wiki .. if there is 
> something not mentioned there .. ask the author of the RFC why that is and 
> see if they are willing to add it there and notify the list once. If the 
> author in question is unwilling to add it .. then .. and only then bring it 
> back to this list.

+1


> regards,
> Lukas Kahwe Smith
> m...@pooteeweet.org
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

Re: [PHP-DEV] Strict typing

[Melanie Rhianna Lewis]

On 11 Aug 2010, at 17:01, Elizabeth M Smith wrote:

> Well this is turning into a real flamefest.

I'm now totally confused to be honest.

> Personally I really HATE the 5.3 implementation of "typehints" - heck you 
> can't even typehint arrays with an arrayobject instance, it's not hinting in 
> any way shape or form and is generally broken.
> 
> On the other hand I'd like to be able to have the same control of parameters 
> in my userland code that I do in extensions - namely the same control I get 
> with zend_parse_parameters.  And the same errors/warnings I get with 
> zend_parse_parameters

This.

> Any reason we can't expose the logic included there into userland? Would make 
> internal functions and userland functions work the same and act the same.

> 
> Anyway, at this point there's a lot of arguing and very little consensus.  
> I'm kind of tempted to say maybe all the people on the internals mailing list 
> are a bit myopic in their viewpoints, and maybe this does need to get out to 
> a wider community (php.general perhaps?) since the guy hacking on a wordpress 
> plugin is every bit as much a PHP user as any of us.

Absolutely.

Melanie


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

Re: [PHP-DEV] Strict typing

[Gustavo Lopes]

On Wed, 11 Aug 2010 16:03:14 +0100, Alexey Zakhlestin   
wrote:



2010/8/11 Ryan Panning :


Because the current syntax used for type hinting
classes/arrays is strict. If changed, you would need to specify that  
scaler

types are weak but classnames are strict and now you have a WTH moment.


Not really. Class type-hinting is not strict. The only reason why it
looks strict is, that PHP doesn't provide userland ways for
object-casting.
As far as I remember, zend-engine, underneath, actually has hook for
casting. And nothing stops us from supporting such casting with hints,
eventually.



If you're referring to the cast_object handler, the only thing it can  
specify in terms of the target type  is IS_STRING, IS_OBJECT, etc.


I don't think what we have now and both strategies that are being  
considered are directly comparable, so the "the current type hinting*  
is/is not strict" and "the new strategy is/is not consistent with current  
type hinting" are just rhetoric.


I'm my opinion, what we should strive for is consistency with the only  
comparable thing, the current parsing API, zend_parse_parameters. If an  
internal function says it accepts an array, it can only take an array**.  
If it says it only accepts an object of a certain type, it checks the  
inheritance hierarchy***. So the current type hinting implementation is  
already consistent with zend_parse_parameters.


Unfortunately, both competing options want to deviate from this:
- The strict side wants a simple, 'gettype' like check, that has nothing  
to do with the current API.
- The weak side thinks the current parameter parsing API is a bit loose  
(for instance, if I'm not mistaken, all the scalars are automatically  
converted to bool), so it's better to create a whole new set of rules,  
even though they will still deviate slightly from the current API.


In my opinion, the transition should be made slowly. First, by raising a  
warning on the undesirable automatic conversions we don't want, and  
finally disallowing them altogether and introducing a compatible  
user-space type hinting.


* terminology objections aside
** the rare 'H'/'A', which also take an object, excluded)
*** 'o' can also be given, which accepts all the object types

--
Gustavo Lopes

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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Melanie Rhianna Lewis]

On 11 Aug 2010, at 15:13, Zeev Suraski wrote:

> Maybe I'm old school, but in my opinion, trunk should only contain 
> agreed-upon features.  It should also always build and pass tests 
> successfully.  It's not the wild-west version of PHP, it's PHP's next 
> version, in progress.  Want to work on something experimental or 
> controversial?  Do that in a branch, merge it if & when it gets accepted to 
> the language.

I think that depends upon (a) consistency with how it was done last time; and 
(b) what you're used to.  I've worked on plenty of projects where the trunk was 
bleeding edges and branches are used for release preparation.

Melanie


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

Re: [PHP-DEV] Strict typing

[Kalle Sommer Nielsen]

Hi Elizabeth

2010/8/11 Elizabeth M Smith :
> Well this is turning into a real flamefest.
>
> Personally I really HATE the 5.3 implementation of "typehints" - heck you
> can't even typehint arrays with an arrayobject instance, it's not hinting in
> any way shape or form and is generally broken.
>
> On the other hand I'd like to be able to have the same control of parameters
> in my userland code that I do in extensions - namely the same control I get
> with zend_parse_parameters.  And the same errors/warnings I get with
> zend_parse_parameters

Sara wrote an extension for zend_parse_parameters() to expose it to
userland and its available in PECL:
http://svn.php.net/viewvc/pecl/params/trunk/

Im a +1 for exposing such functionality from the core/stdlib.



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

Re: [PHP-DEV] Strict typing

[Elizabeth M Smith]

Well this is turning into a real flamefest.

Personally I really HATE the 5.3 implementation of "typehints" - heck 
you can't even typehint arrays with an arrayobject instance, it's not 
hinting in any way shape or form and is generally broken.


On the other hand I'd like to be able to have the same control of 
parameters in my userland code that I do in extensions - namely the same 
control I get with zend_parse_parameters.  And the same errors/warnings 
I get with zend_parse_parameters


Any reason we can't expose the logic included there into userland? 
Would make internal functions and userland functions work the same and 
act the same.


Anyway, at this point there's a lot of arguing and very little 
consensus.  I'm kind of tempted to say maybe all the people on the 
internals mailing list are a bit myopic in their viewpoints, and maybe 
this does need to get out to a wider community (php.general perhaps?) 
since the guy hacking on a wordpress plugin is every bit as much a PHP 
user as any of us.


Thanks,
Elizabeth M Smith

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

Re: [PHP-DEV] Strict typing

[Ryan Panning]

Johannes Schlüter wrote:

Good that this discussion happens in a secret place on a list no
"community" members can see.

Oh wait. It doesn't. Oh and wait we let users participate!

And "we know best" - well part of this is that for doing the discussion
in a sane way you need some minimum knowledge and some experience. 


I talked to PHP users on different conferences, even about type hints at
different conferences and such and if you ask them "Do you want type
hints?" most of them will answer "yes, yes, yes!" until you explain the
consequences, like I did a bit on my blog[1] (again very secret
discussion ignoring all users!). Then suddenly they agree that type
hints are bad.

But that's not their opinion. That's manipulation. Asking the question
the way you want while providing the material to support your point. (It
is hard to ask this in an "neutral" way) For _real_ argumentation you
need to really think through it. And here on the list are people who try
to do this.

Many people participating in this discussion discussed other problems,
too and then found out what the bad consequences are, and learned from
these mistakes. Others are willing to invest time to think through
ideas. Few just flame/try to push their opinion. But still this is an
open list. (sometimes unfortunately)

johannes

[1] http://schlueters.de/blog/archives/139-Scalar-type-hints-in-PHP-trunk.html



Fair enough. I just feel like if I don't follow this newsgroup then I 
won't know what's going on with PHP. For others like myself, I don't 
know about other places to watch, such as your blog or the IRC. Votes 
that I have casted here have been counted, and I thank you for that. But 
it just seems hard to follow at times.


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

Re: [PHP-DEV] Strict typing

[Johannes Schlüter]

On Wed, 2010-08-11 at 10:17 -0500, Ryan Panning wrote:
> One other comment I forgot with my original post:
> Why not leave the choice (strict/weak) up to the end users by 
> implementing both using the syntax I commented about? Is one way or
> the 
> other so bad that it can't be implemented? 

Yes. It was clearly said by quite many people that strict typing is so
bad. Way clearer than almost any other decision. So please lets end this
thread and move on to undecided questions.

johannes



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

Re: [PHP-DEV] Strict typing

[Johannes Schlüter]

On Wed, 2010-08-11 at 09:55 -0500, Ryan Panning wrote:
> IMO some of these debates should be brought to the end 
> users. Who uses PHP in the end? The users. (And yes, I know the devs 
> here do to..) What is one thing most companies go by? The customers
> come first. This "we know best" attitude here is gone way to far.
> Please don't just leave this here, because you'll hear it from the
> users in the end anyway. A good community is one who communicates.
> Thanks

Good that this discussion happens in a secret place on a list no
"community" members can see.

Oh wait. It doesn't. Oh and wait we let users participate!

And "we know best" - well part of this is that for doing the discussion
in a sane way you need some minimum knowledge and some experience. 

I talked to PHP users on different conferences, even about type hints at
different conferences and such and if you ask them "Do you want type
hints?" most of them will answer "yes, yes, yes!" until you explain the
consequences, like I did a bit on my blog[1] (again very secret
discussion ignoring all users!). Then suddenly they agree that type
hints are bad.

But that's not their opinion. That's manipulation. Asking the question
the way you want while providing the material to support your point. (It
is hard to ask this in an "neutral" way) For _real_ argumentation you
need to really think through it. And here on the list are people who try
to do this.

Many people participating in this discussion discussed other problems,
too and then found out what the bad consequences are, and learned from
these mistakes. Others are willing to invest time to think through
ideas. Few just flame/try to push their opinion. But still this is an
open list. (sometimes unfortunately)

johannes

[1] http://schlueters.de/blog/archives/139-Scalar-type-hints-in-PHP-trunk.html


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

Re: [PHP-DEV] Strict typing

[Ryan Panning]

Lukas Kahwe Smith wrote:

...

anyway .. for the love of god, could be please stop arguing in circles, nothing 
.. really nothing that people brought forth pro/con any approach in regards to 
type checking/hinting whatever hasn't been mentioned on this list multiple 
times.

...


I agree with you, another topic that has been debated to death here. 
Between this and the namespace separator debate, it's been hard to keep up.


One other comment I forgot with my original post:
Why not leave the choice (strict/weak) up to the end users by 
implementing both using the syntax I commented about? Is one way or the 
other so bad that it can't be implemented?


At this point I feel like a decision should be made and stick with it. I 
would use this feature either way (strict/weak/both). It'll mainly be 
used in a framework so the users of that are going to have to deal with 
the end result. But if I had to vote it would be for weak. Thanks again.


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

Re: [PHP-DEV] Strict typing

[Lukas Kahwe Smith]

On 11.08.2010, at 16:55, Ryan Panning wrote:

> Now, changing the current implementation to "weak type hinting" would be more 
> confusing. Because the current syntax used for type hinting classes/arrays is 
> strict. If changed, you would need to specify that scaler types are weak but 
> classnames are strict and now you have a WTH moment.


actually for objects its fairly along the lines of what is being proposed with 
weak typing, since the type hints for objects do consider inheritance. so you 
do not need to pass in exactly the object that is type hinted, but instead you 
can also pass in any subclass (an integer is a float).

anyway .. for the love of god, could be please stop arguing in circles, nothing 
.. really nothing that people brought forth pro/con any approach in regards to 
type checking/hinting whatever hasn't been mentioned on this list multiple 
times.

please please please please .. read the RFC's on the wiki .. if there is 
something not mentioned there .. ask the author of the RFC why that is and see 
if they are willing to add it there and notify the list once. If the author in 
question is unwilling to add it .. then .. and only then bring it back to this 
list.

regards,
Lukas Kahwe Smith
m...@pooteeweet.org




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

Re: [PHP-DEV] Strict typing

[Alexey Zakhlestin]

2010/8/11 Ryan Panning :

> Because the current syntax used for type hinting
> classes/arrays is strict. If changed, you would need to specify that scaler
> types are weak but classnames are strict and now you have a WTH moment.

Not really. Class type-hinting is not strict. The only reason why it
looks strict is, that PHP doesn't provide userland ways for
object-casting.
As far as I remember, zend-engine, underneath, actually has hook for
casting. And nothing stops us from supporting such casting with hints,
eventually.

-- 
Alexey Zakhlestin
http://www.milkfarmsoft.com/

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

Re: [PHP-DEV] Strict typing

[Ryan Panning]

Victor Bolshov wrote:

Having two similar syntaxes that work differently - would make the
situation even worse that it is now - I beleive. And I totally agree
with Rasmus - strict typed language mustnt be called PHP. (Just a poor
user's notice to all of you internals' geeks out there)

2010/8/11 Stas Malyshev :

Hi!


1. right now we *have* strict type checks for classes and arrays in the
   form of "classname" or "array"

Because classes and arrays were never intechangeable types and there was
never implicit or explicit conversion between SplRecursiveTreeIterator and
Zend_Pdf_Generator - it doesn't even make sense to suggest it. There always
was conversion between int and string or int and bool. These two things are
completely different.


2. the strict scalary type hint patch reuses this same syntax in the
   form of  to do the same thing in function arguments

It's not a good thing. As I mentioned, primitive types and classes are very
different in their use cases and established patterns in PHP. Primitive
types are largely interchangeable, classes are not. (As for arrays, arrays
really should be a class by their usage patterns etc. but for historic
reasons... you know)


3. we have casting type hints in the rest of the code in the form of
   "(int)".

Just to make it simpler and less confusing, of course. It's nothing like
language having two features that look almost exactly the same but work in
different way, and using plenty of ()s is an added bonus for all Lisp fans
out there.


Some people don't like strict typehints, but the syntax as it currently
is regarding type hints is *consistent*. Now, to allow both strict and
casting hints, the logical step seems to be, to give the weak typehint
advocates their tool as well:

Calling something that works completely differently from all the established
patterns of PHP - like internal functions, etc. - "*consistent*" requires
totally new definition of this word.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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



Why do you think the two syntax's would be more complex!? IMO it is very 
clear what each would do.


The "strict type hinting", foo(int $var), is the same as the current 
"type hinting" for classes and arrays. It's required to be of that type, 
plain and simple.


The "weak type hinting", foo((int) $var), is the same as casting any 
other var, plain and simple. It will try to be casted to the specified 
type, with an error if it can't.


I'm willing to bet that if you bring this to the end users they will 
agree that it's easy to understand. Why try to figure out a new syntax 
for something that already exists!?


Now, changing the current implementation to "weak type hinting" would be 
more confusing. Because the current syntax used for type hinting 
classes/arrays is strict. If changed, you would need to specify that 
scaler types are weak but classnames are strict and now you have a WTH 
moment.


Not sure how much my opinion matters here though because I'm just an end 
user of PHP. IMO some of these debates should be brought to the end 
users. Who uses PHP in the end? The users. (And yes, I know the devs 
here do to..) What is one thing most companies go by? The customers come 
first. This "we know best" attitude here is gone way to far. Please 
don't just leave this here, because you'll hear it from the users in the 
end anyway. A good community is one who communicates. Thanks


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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Richard Quadling]

On 11 August 2010 15:13, Zeev Suraski  wrote:
> At 15:14 11/08/2010, Richard Quadling wrote:
>>
>> On 11 August 2010 12:10, Zeev Suraski  wrote:
>> > We need to remove strict typing from trunk before we release anything
>> > 'official' from php.net
>>
>> I thought "trunk" is, to some degree, the "work in progress" /
>> "developers only", YMMV branch. Pretty much anything/everything in
>> there is subject to change. No money back guarantees. Etc.
>
> Supposedly we switched to this strategy although I'm not sure why, nor I
> recall any discussion about it - although I may have missed it.  We never
> ever treated HEAD this way in the CVS days.  So sure, now it's called
> 'trunk', but why we should deviate from our decision making processes (as
> lax as they may be) because we changed version control systems is beyond me.
>
>> For an official release, even as a "Here is what we are working on. It
>> might not be perfect, but we like it" release, a separate branch would
>> be created.
>
> It's really not a matter of branches, trunk or HEAD.  It's a matter of what
> 'php.net' puts its virtual stamp of approval on.  If 5.4 alpha 1 came out
> with strict typing in it, it would send two very strong messages to the PHP
> community:
>
> 1.  The next version of PHP is going to be named 5.4 - something that wasn't
> agreed upon (although personally I don't mind that much).
> 2.  "We think strict typing is a good idea, here, play with it".  Well,
> turns out that the collective 'we' doesn't really think that at all.  It's
> no big news either, it's been known for many months.
>
> That goes back to my first paragraph.  Personally, I don't like the 'shoot
> first, ask questions later' approach that we supposedly switched to
> recently.  To me it makes a whole lot more sense to discuss first, and only
> once a decision is made - go ahead and implement it.  Whether we go formal
> with RFCs or less formal on internals@ (depending on the scope) - either way
> it's way better than committing first and only then discussing.  Once in
> trunk we suddenly need a great reason to remove it, since trunk is now the
> new 'status quo'.  Thankfully in the case of strict typing there was a
> strong, clear message from the community 'don't do it', but what about
> smaller features?
>
> 'Shoot first, ask questions later' equates 'bias for change'.  Is that where
> we want to be?  IMHO no, we should carefully consider every change we make
> to the core language at this point in time.
>
> Maybe I'm old school, but in my opinion, trunk should only contain
> agreed-upon features.  It should also always build and pass tests
> successfully.  It's not the wild-west version of PHP, it's PHP's next
> version, in progress.  Want to work on something experimental or
> controversial?  Do that in a branch, merge it if & when it gets accepted to
> the language.
>
> Zeev
>
>

Thank you for that Zeev.


-- 
Richard Quadling.

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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Lukas Kahwe Smith]

On 11.08.2010, at 16:13, Zeev Suraski wrote:

> Maybe I'm old school, but in my opinion, trunk should only contain 
> agreed-upon features.  It should also always build and pass tests 
> successfully.  It's not the wild-west version of PHP, it's PHP's next 
> version, in progress.  Want to work on something experimental or 
> controversial?  Do that in a branch, merge it if & when it gets accepted to 
> the language.


+1

actually this is in a lot of ways new school, since even though we do not yet 
use one of those fancy DVCS, with svn we have a much better work flow already 
to handle feature branches.

regards,
Lukas Kahwe Smith
m...@pooteeweet.org




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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Zeev Suraski]

At 15:14 11/08/2010, Richard Quadling wrote:

On 11 August 2010 12:10, Zeev Suraski  wrote:
> We need to remove strict typing from trunk before we release anything
> 'official' from php.net

I thought "trunk" is, to some degree, the "work in progress" /
"developers only", YMMV branch. Pretty much anything/everything in
there is subject to change. No money back guarantees. Etc.


Supposedly we switched to this strategy although I'm not sure why, 
nor I recall any discussion about it - although I may have missed 
it.  We never ever treated HEAD this way in the CVS days.  So sure, 
now it's called 'trunk', but why we should deviate from our decision 
making processes (as lax as they may be) because we changed version 
control systems is beyond me.



For an official release, even as a "Here is what we are working on. It
might not be perfect, but we like it" release, a separate branch would
be created.


It's really not a matter of branches, trunk or HEAD.  It's a matter 
of what 'php.net' puts its virtual stamp of approval on.  If 5.4 
alpha 1 came out with strict typing in it, it would send two very 
strong messages to the PHP community:


1.  The next version of PHP is going to be named 5.4 - something that 
wasn't agreed upon (although personally I don't mind that much).
2.  "We think strict typing is a good idea, here, play with 
it".  Well, turns out that the collective 'we' doesn't really think 
that at all.  It's no big news either, it's been known for many months.


That goes back to my first paragraph.  Personally, I don't like the 
'shoot first, ask questions later' approach that we supposedly 
switched to recently.  To me it makes a whole lot more sense to 
discuss first, and only once a decision is made - go ahead and 
implement it.  Whether we go formal with RFCs or less formal on 
internals@ (depending on the scope) - either way it's way better than 
committing first and only then discussing.  Once in trunk we suddenly 
need a great reason to remove it, since trunk is now the new 'status 
quo'.  Thankfully in the case of strict typing there was a strong, 
clear message from the community 'don't do it', but what about 
smaller features?


'Shoot first, ask questions later' equates 'bias for change'.  Is 
that where we want to be?  IMHO no, we should carefully consider 
every change we make to the core language at this point in time.


Maybe I'm old school, but in my opinion, trunk should only contain 
agreed-upon features.  It should also always build and pass tests 
successfully.  It's not the wild-west version of PHP, it's PHP's next 
version, in progress.  Want to work on something experimental or 
controversial?  Do that in a branch, merge it if & when it gets 
accepted to the language.


Zeev


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

Re: [PHP-DEV] Strict typing

[Brian Moon]

On 8/11/10 1:03 AM, Zeev Suraski wrote:

We've also had quite a lengthy discussion on this topic, and there
was more support for 'weak' typing then there was for strict typing.


Yes, I would like to restate the obvious from my email in May:


Really, I am confused what the argument is about. We already decided
how this should work years ago. It should work just like the code
below. Having user land functions work different than built in
functions is the most confusing thing you can do. Unless of course
someone plans on fixing all the internal functions too.





$ php test.php

> string(4) "1.25"
> float(1.3)


Warning: substr() expects parameter 1 to be string, array given in
/Users/brianm/test.php on line 17

> NULL
> float(0)

--

Brian.

http://brian.moonspot.net/

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

RE: [PHP-DEV] Strict typing (was: Typehints)

[Andi Gutmans]

I wouldn't mind living with neither but I think it's two separate discussions.

> -Original Message-
> From: Ilia Alshanetsky [mailto:i...@prohost.org]
> Sent: Wednesday, August 11, 2010 3:52 AM
> To: Zeev Suraski
> Cc: Stas Malyshev; Johannes Schlüter; Kalle Sommer Nielsen; Internals;
> Derick Rethans
> Subject: Re: [PHP-DEV] Strict typing (was: Typehints)
> 
> I think that weak type-hinting defeats the whole purpose of the feature and I
> would rather not have it than have a non-obvious implementation.
> 
> -1
> 
> On Wed, Aug 11, 2010 at 2:03 AM, Zeev Suraski  wrote:
> > At 01:47 11/08/2010, Stas Malyshev wrote:
> >>
> >> Hi!
> >>
> >>> For the record: I consider the current implementation as (one of)
> >>> the biggest mistakes in the last ten years.
> >>
> >> I agree completely. The fact that obvious absence of consensus is
> >> ignored and we are releasing feature that clearly has no consensus
> >> behind it as a part of an official release - when we have killed much
> >> lesser things for much lesser reasons - I think it is a very bad 
> >> development.
> >
> > I agree completely too.
> >
> > We've also had quite a lengthy discussion on this topic, and there was
> > more support for 'weak' typing then there was for strict typing.
> >
> > The response to Johannes's blog also don't leave much room for
> > speculation regarding what the community at large thinks.
> >
> > Facts:
> > - When we introduced type hints, one of the 'conditions' were that
> > we'll never, ever have type hints for scalars - for many different
> > reasons - the strongest of which it simply doesn't fit PHP's theme.
> > - We managed to come up with an alternative solution, in the form of
> > auto-converting type hints for scalars, which does in fact fit PHP's
> > theme perfectly.
> > - I suggested we actually take the opportunity to slightly modify
> > PHP's conversion rules in esoteric cases, where our historical
> > decision is probably not the right one (e.g., silently converting
> > "abc" into 0 in case of integer context - instead emit a new E_TYPE
> > warning that would be off by default).
> >
> > My view in terms of preferences:
> > #1 - Auto-converting type hints + minor changes to PHP's conversion
> > rules
> > #2 - Auto-converting type hints
> > #3 - Doing nothing
> > #inf - Introducing strict typing into PHP (current trunk status)
> >
> > As Stas said - there's clearly anything but consensus around strict
> > typing, so our 'default' in case we can't reach agreement is #3 - the status
> quo.
> >  As everyone told me when this feature was committed to trunk - "it
> > doesn't mean anything, it's just trunk".  Let's stand behind that
> > statement and revert it.
> >
> > Strict typing should go away before any 'official' package comes out
> > of php.net.
> >
> > Zeev
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> > visit: http://www.php.net/unsub.php
> >
> >
> 
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
> http://www.php.net/unsub.php


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

RE: [PHP-DEV] Strict typing (was: Typehints)

[Andi Gutmans]

> -Original Message-
> From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org]
> Sent: Wednesday, August 11, 2010 5:19 AM
> To: rquadl...@googlemail.com
> Cc: Zeev Suraski; Ilia Alshanetsky; Stas Malyshev; Johannes Schlüter; Kalle
> Sommer Nielsen; Internals; Derick Rethans
> Subject: Re: [PHP-DEV] Strict typing (was: Typehints)
> 
> 
> On 11.08.2010, at 14:14, Richard Quadling wrote:
> 
> > So, the trunk keeps strict typing.
> > 
> no .. a controversial patch like this should never have gotten into trunk
> without a vote. the only place for this patch in the svn.php.net repo would be
> a feature branch.

I completely agree. I don't know how this patch sneaked in and there clearly is 
a vast majority against it. We have discussed several times over the years on 
why such strict type hinting does not make sense for PHP.

Andi


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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Arvids Godjuks]

2010/8/11 Ilia Alshanetsky :
> I think that weak type-hinting defeats the whole purpose of the
> feature and I would rather not have it than have a non-obvious
> implementation.
>
> -1
>

I would like to point out an argument, posted in the "Typehints (was
Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1)" thread by Jonathan
Bond-Caron, quoting:
"It's only consistent in the function declarations but *completely*
inconsistent with how the rest of the language works."

He took the words out of my mouth.

The auto-convert feature only touches the idea that 1 => "1", "1" => 1
conversions should take place automatically. In the case of "abcd" =>
0 we emit an error message. As it was mentioned in the RFC, the idea
is not only to make type hint's this way, but _also_ to change the
language conversion rules acordingly to match the type hinting
auto-conversion rules. That way the conversion rules are made more
strict and type hints get some freedom instead of going into E_FATAL
everytime a developer misses string to int (and other similiar)
conversion in the code before passing data to objects/functions/API.
The conversions don't just go completly silent if inapropriate value
is passed to the function/method witch can't be converted
transparently to the required type. It gives you the error message and
it's your choise to ignore it or fix it. Strict type hintng will just
bring tons of code that does:
settype('integer', $total);
settype('integer', $per_page);
settype('integer', $page);
pager($page, $total, $per_page);

It will have to be written to make sure the variables have the right
type. Especially $page, witch usually comes via $_GET. Instead of just
checking for is_numeric now we have also to convert the type.

I just have an empression that you don't write much PHP code or you
work on very big and highly sophisticated projects, where the
situation is different. You leaving out the majority of PHP code
written for the middle and small scale projects, witch usually done by
far more simplier tools, sometimes even just using the plain old PHP
without a framework (and yes, sometimes it's just faster that way!).

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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Lukas Kahwe Smith]

On 11.08.2010, at 14:14, Richard Quadling wrote:

> So, the trunk keeps strict typing.


no .. a controversial patch like this should never have gotten into trunk 
without a vote. the only place for this patch in the svn.php.net repo would be 
a feature branch.

regards,
Lukas Kahwe Smith
m...@pooteeweet.org




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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Richard Quadling]

On 11 August 2010 12:10, Zeev Suraski  wrote:
> We need to remove strict typing from trunk before we release anything
> 'official' from php.net

I thought "trunk" is, to some degree, the "work in progress" /
"developers only", YMMV branch. Pretty much anything/everything in
there is subject to change. No money back guarantees. Etc.

For an official release, even as a "Here is what we are working on. It
might not be perfect, but we like it" release, a separate branch would
be created.

If strict typing isn't wanted in the new branch, then it doesn't go
into the new branch (I have a limited understanding of what that
entails, so I suspect I'm missing a lot of important processes by
saying that - thankfully, no one will ever consider _me_ for the role
of RM!).

So, the trunk keeps strict typing.

Richard Quadling.

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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Zeev Suraski]

That's not the issue on the table now.

We need to remove strict typing from trunk before we release anything 
'official' from php.net, and the sooner the better.  It's clearly not 
something there's consensus over, almost the opposite.


We should discuss the merits of auto-converting type hints separately 
- and if we decide not to have it that's fine.  It has nothing to do 
with the fact there's almost consensus not to have strict typing in PHP.


Zeev

At 13:52 11/08/2010, Ilia Alshanetsky wrote:

I think that weak type-hinting defeats the whole purpose of the
feature and I would rather not have it than have a non-obvious
implementation.

-1

On Wed, Aug 11, 2010 at 2:03 AM, Zeev Suraski  wrote:
> At 01:47 11/08/2010, Stas Malyshev wrote:
>>
>> Hi!
>>
>>> For the record: I consider the current implementation as (one of) the
>>> biggest mistakes in the last ten years.
>>
>> I agree completely. The fact that obvious absence of consensus is ignored
>> and we are releasing feature that clearly has no consensus behind it as a
>> part of an official release - when we have killed much lesser things for
>> much lesser reasons - I think it is a very bad development.
>
> I agree completely too.
>
> We've also had quite a lengthy discussion on this topic, and there was more
> support for 'weak' typing then there was for strict typing.
>
> The response to Johannes's blog also don't leave much room for speculation
> regarding what the community at large thinks.
>
> Facts:
> - When we introduced type hints, one of the 'conditions' were that we'll
> never, ever have type hints for scalars - for many different reasons - the
> strongest of which it simply doesn't fit PHP's theme.
> - We managed to come up with an alternative solution, in the form of
> auto-converting type hints for scalars, which does in fact fit PHP's theme
> perfectly.
> - I suggested we actually take the opportunity to slightly modify PHP's
> conversion rules in esoteric cases, where our historical decision is
> probably not the right one (e.g., silently converting "abc" into 0 in case
> of integer context - instead emit a new E_TYPE warning that would be off by
> default).
>
> My view in terms of preferences:
> #1 - Auto-converting type hints + minor changes to PHP's conversion rules
> #2 - Auto-converting type hints
> #3 - Doing nothing
> #inf - Introducing strict typing into PHP (current trunk status)
>
> As Stas said - there's clearly anything but consensus around strict typing,
> so our 'default' in case we can't reach agreement is #3 - the status quo.
>  As everyone told me when this feature was committed to trunk - "it doesn't
> mean anything, it's just trunk".  Let's stand behind that statement and
> revert it.
>
> Strict typing should go away before any 'official' package comes out of
> php.net.
>
> Zeev
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Lukas Kahwe Smith]

On 11.08.2010, at 10:53, Pierre Joye wrote:

> On Wed, Aug 11, 2010 at 8:03 AM, Zeev Suraski  wrote:
> 
>> Facts:
> 
> There are two facts that matter right now, imo:
> 
> - There is no 5.4 or whatever other version as of now.
> - There is no RM either.
> 
> I don't know why nobody cares (well I do ;), but this is totally
> insane. Do we ever learn? PHP6, the last 5.4 horrible episode, etc.
> And as we clearly see today, we are not ready.


+1

regards,
Lukas Kahwe Smith
m...@pooteeweet.org




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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Ilia Alshanetsky]

I think that weak type-hinting defeats the whole purpose of the
feature and I would rather not have it than have a non-obvious
implementation.

-1

On Wed, Aug 11, 2010 at 2:03 AM, Zeev Suraski  wrote:
> At 01:47 11/08/2010, Stas Malyshev wrote:
>>
>> Hi!
>>
>>> For the record: I consider the current implementation as (one of) the
>>> biggest mistakes in the last ten years.
>>
>> I agree completely. The fact that obvious absence of consensus is ignored
>> and we are releasing feature that clearly has no consensus behind it as a
>> part of an official release - when we have killed much lesser things for
>> much lesser reasons - I think it is a very bad development.
>
> I agree completely too.
>
> We've also had quite a lengthy discussion on this topic, and there was more
> support for 'weak' typing then there was for strict typing.
>
> The response to Johannes's blog also don't leave much room for speculation
> regarding what the community at large thinks.
>
> Facts:
> - When we introduced type hints, one of the 'conditions' were that we'll
> never, ever have type hints for scalars - for many different reasons - the
> strongest of which it simply doesn't fit PHP's theme.
> - We managed to come up with an alternative solution, in the form of
> auto-converting type hints for scalars, which does in fact fit PHP's theme
> perfectly.
> - I suggested we actually take the opportunity to slightly modify PHP's
> conversion rules in esoteric cases, where our historical decision is
> probably not the right one (e.g., silently converting "abc" into 0 in case
> of integer context - instead emit a new E_TYPE warning that would be off by
> default).
>
> My view in terms of preferences:
> #1 - Auto-converting type hints + minor changes to PHP's conversion rules
> #2 - Auto-converting type hints
> #3 - Doing nothing
> #inf - Introducing strict typing into PHP (current trunk status)
>
> As Stas said - there's clearly anything but consensus around strict typing,
> so our 'default' in case we can't reach agreement is #3 - the status quo.
>  As everyone told me when this feature was committed to trunk - "it doesn't
> mean anything, it's just trunk".  Let's stand behind that statement and
> revert it.
>
> Strict typing should go away before any 'official' package comes out of
> php.net.
>
> Zeev
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Pierre Joye]

On Wed, Aug 11, 2010 at 8:03 AM, Zeev Suraski  wrote:

> Facts:

There are two facts that matter right now, imo:

- There is no 5.4 or whatever other version as of now.
- There is no RM either.

I don't know why nobody cares (well I do ;), but this is totally
insane. Do we ever learn? PHP6, the last 5.4 horrible episode, etc.
And as we clearly see today, we are not ready.


-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Lukas Kahwe Smith]

Hi,

why are we discussing this again?
get the RFC's fixed up (though I would assume by now they are already) and do a 
vote and of story
without a vote the status quo from the last release should be maintained for 
such a controversial feature, aka if there is no consensus then the strict type 
check changes should be moved to a feature branch.

just committing, and then try to wait for a moment when nobody complains (guess 
it didnt work this time) to release the commit has been done before i guess, 
but its not the way to go .. for obvious reasons.

regards,
Lukas Kahwe Smith
m...@pooteeweet.org




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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Victor Bolshov]

+1. Strict typing will only prevent PHP from being itself, while not
providing the advantages of a real statically types language (as Stas
Malyshev has mentioned in another thread of discussion).

2010/8/11 Arvids Godjuks :
> Completly agree with Zeev, most russian comunity is for the weak type
> hinting. Many would like strict, but most of the pro strict type
> hinters understand that PHP and strict type hinting not match and vote
> for type hints with auto converting.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
С уважением,
Виктор

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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Arvids Godjuks]

Completly agree with Zeev, most russian comunity is for the weak type
hinting. Many would like strict, but most of the pro strict type
hinters understand that PHP and strict type hinting not match and vote
for type hints with auto converting.

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

Re: [PHP-DEV] Strict typing

[Stas Malyshev]

Hi!


I'm sorry but I have no idea what you're talking about there =\ PHP
has a bunch of different types, the current type hinting (typechecking


"int" is a different kind of type from Zend_Controller_Factory and 
SimpleXML - the same kind of types are "int" and "object". The former 
are engine types (IS_INTEGER, IS_OBJECT), the latter are classes.



I very much can, it's just not my intention. I want to be able to use
type hinting/type checking as a sanity check. If I write a method
whose signature is foo(int $n) I signal my intention to only accept


Then you should use statically typed language. There's no law saying 
every code on the planet should be written in PHP, and PHP is not a 
statically typed language. So by bolting static typing onto it you are 
using wrong tool for the job.



If PHP was meant to prevent programmers from controlling the type of
their variables then I'm afraid there's been a misunderstanding and


PHP and dynamic languages in general are not preventing people from 
knowing the types of variables, they however remove a number of 
annoyances that come with static types. You want to bring all those back 
- and that without the benefits that are compensating for those 
annoyances in compiled languages - meaning being sure upfront that the 
code always gets proper data in proper places. You don't know that 
unless you statically type and compile your whole code - so you just 
traded flexibility and API agility for nothing.



I'm not sure what you meant by "objects of classes can not [be
converted into another type]". Arrays can be cast as booleans (false


There are no generic rules that allow conversion between two classes - 
such as SimpleXML and Exception, for example. In general, conversions 
between classes don't happen in the engine. Conversion between IS_* 
types happen all the time.



TL;DR: I always thought PHP would help me control the type of my
variables instead of forcing my userland code to mirror PHP's internal
functions.


If you want strict typing ("control the type of my variables") I'm 
afraid you're using not only wrong language but wrong paradigm. You 
should be using statically typed language. Try C# or Java or Scala or 
something like that. Just having parameter typing won't help you - you'd 
just kick the problem around the code, it will be now it variables 
upstream, etc.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] Strict typing

[Lester Caine]

Zeev Suraski wrote:

Strict typing should go away before any 'official' package comes out of
php.net.


+1 from me as well.
And it is nice to hear that I'm not on my own in that ...

--
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//
Firebird - http://www.firebirdsql.org/index.php

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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Adam Richardson]

On Wed, Aug 11, 2010 at 2:03 AM, Zeev Suraski  wrote:

> At 01:47 11/08/2010, Stas Malyshev wrote:
>
>> Hi!
>>
>>  For the record: I consider the current implementation as (one of) the
>>> biggest mistakes in the last ten years.
>>>
>>
>> I agree completely. The fact that obvious absence of consensus is ignored
>> and we are releasing feature that clearly has no consensus behind it as a
>> part of an official release - when we have killed much lesser things for
>> much lesser reasons - I think it is a very bad development.
>>
>
> I agree completely too.
>
> We've also had quite a lengthy discussion on this topic, and there was more
> support for 'weak' typing then there was for strict typing.
>
> The response to Johannes's blog also don't leave much room for speculation
> regarding what the community at large thinks.
>
> Facts:
> - When we introduced type hints, one of the 'conditions' were that we'll
> never, ever have type hints for scalars - for many different reasons - the
> strongest of which it simply doesn't fit PHP's theme.
> - We managed to come up with an alternative solution, in the form of
> auto-converting type hints for scalars, which does in fact fit PHP's theme
> perfectly.
> - I suggested we actually take the opportunity to slightly modify PHP's
> conversion rules in esoteric cases, where our historical decision is
> probably not the right one (e.g., silently converting "abc" into 0 in case
> of integer context - instead emit a new E_TYPE warning that would be off by
> default).
>
> My view in terms of preferences:
> #1 - Auto-converting type hints + minor changes to PHP's conversion rules
> #2 - Auto-converting type hints
> #3 - Doing nothing
> #inf - Introducing strict typing into PHP (current trunk status)
>
> As Stas said - there's clearly anything but consensus around strict typing,
> so our 'default' in case we can't reach agreement is #3 - the status quo.
>  As everyone told me when this feature was committed to trunk - "it doesn't
> mean anything, it's just trunk".  Let's stand behind that statement and
> revert it.
>
> Strict typing should go away before any 'official' package comes out of
> php.net.
>
> Zeev
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
+1 (All of what Zeev said)

-- 
Nephtali:  PHP web framework that functions beautifully
http://nephtaliproject.com

Re: [PHP-DEV] Strict typing (was: Typehints)

[Zeev Suraski]

At 01:47 11/08/2010, Stas Malyshev wrote:

Hi!


For the record: I consider the current implementation as (one of) the
biggest mistakes in the last ten years.


I agree completely. The fact that obvious absence of consensus is 
ignored and we are releasing feature that clearly has no consensus 
behind it as a part of an official release - when we have killed 
much lesser things for much lesser reasons - I think it is a very 
bad development.


I agree completely too.

We've also had quite a lengthy discussion on this topic, and there 
was more support for 'weak' typing then there was for strict typing.


The response to Johannes's blog also don't leave much room for 
speculation regarding what the community at large thinks.


Facts:
- When we introduced type hints, one of the 'conditions' were that 
we'll never, ever have type hints for scalars - for many different 
reasons - the strongest of which it simply doesn't fit PHP's theme.
- We managed to come up with an alternative solution, in the form of 
auto-converting type hints for scalars, which does in fact fit PHP's 
theme perfectly.
- I suggested we actually take the opportunity to slightly modify 
PHP's conversion rules in esoteric cases, where our historical 
decision is probably not the right one (e.g., silently converting 
"abc" into 0 in case of integer context - instead emit a new E_TYPE 
warning that would be off by default).


My view in terms of preferences:
#1 - Auto-converting type hints + minor changes to PHP's conversion rules
#2 - Auto-converting type hints
#3 - Doing nothing
#inf - Introducing strict typing into PHP (current trunk status)

As Stas said - there's clearly anything but consensus around strict 
typing, so our 'default' in case we can't reach agreement is #3 - the 
status quo.  As everyone told me when this feature was committed to 
trunk - "it doesn't mean anything, it's just trunk".  Let's stand 
behind that statement and revert it.


Strict typing should go away before any 'official' package comes out 
of php.net.


Zeev 



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

Re: [PHP-DEV] Strict typing

[Robert Cummings]

On 10-08-11 12:03 AM, Josh Davis wrote:

On 11 August 2010 02:50, Stas Malyshev  wrote:

Hi!


First of all, I am talking about the typehinting syntax and mechanism
here. As Derick pointed out, current typehints are strict.


Talking about "strict" vs. "non-strict" for class types is meaningless.


By "strict" typehints I meant that no typecasting occurs. Personally
I'm not fan of the "strict" vs "weak" denomination used here either.
I'd rather call them typechecking vs smartcasting.


I'd prefer jugglehints... since I'd like PHP to coerce whatever I pass 
as a parameter to the "hinted" type. This is the PHP way... type 
juggling to save the developer the hassle. If I set a jugglehint of 
"int" then I would expect the value to be coerced to an integer 
regardless of whether 12.0, 12, "12", or "12 brown cows" is passed. The 
process of type juggling is well documented and has been for years. Why 
change that?


Cheers,
Rob.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.

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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Josh Davis]

On 11 August 2010 02:50, Stas Malyshev  wrote:
> Hi!
>
>> First of all, I am talking about the typehinting syntax and mechanism
>> here. As Derick pointed out, current typehints are strict.
>
> Talking about "strict" vs. "non-strict" for class types is meaningless.

By "strict" typehints I meant that no typecasting occurs. Personally
I'm not fan of the "strict" vs "weak" denomination used here either.
I'd rather call them typechecking vs smartcasting.

> can consider them non-strict if you want - they convert if the conversion is
> available, just like the rest of PHP, with only note that conversion is
> *never* available.
> But it's just a semantic game because we are talking about different things
> here. Using the same syntax just confused you to think they are the same,
> but in PHP they are not. There are some languages where there's no primitive
> types or primitive types aren't different from classes - but PHP, for better
> or worse, as of now is not one of them.

I'm sorry but I have no idea what you're talking about there =\ PHP
has a bunch of different types, the current type hinting (typechecking
as per aforementionned denomination) ensures that the argument is the
right type and I hope that adding scalar type hints will not change
that.

> Again, it's just semantic games - you can call it "typehints" or not, your
> choice, but the fact is they did not fixate on the bitwise representation of
> the types - and we shouldn't start fixating on that now. They accept "1"
> when numeric value is needed, why can't you?

I very much can, it's just not my intention. I want to be able to use
type hinting/type checking as a sanity check. If I write a method
whose signature is foo(int $n) I signal my intention to only accept
integers. If a boolean somehow finds its way to that method, it means
that something wrong happened. If I wanted to accept any type of
variable then I wouldn't use a type hint and I would validate the
input with the filter extension. Or I would use type casting.

TL;DR version: "int $n" in the definition means I want an integer. If
I wanted any kind of variable but I wanted it to somehow represent a
number then I would look for a hint such as "number $n". I guess that
"(int) $n" is close enough, since that's what's being used everywhere
else.

> That's exactly what is wrong with it - developer should NOT expect "variable
> of certain type to be passed" (if we are talking about primitive types),
> because PHP is not a strictly typed language, it's a dynamic language.

If PHP was meant to prevent programmers from controlling the type of
their variables then I'm afraid there's been a misunderstanding and
I'd say that extending a feature called "type hinting" to cover all of
PHP's primitive types will only make it worse. I have always thought
that controlling the type of the variables used in userland was my
prerogative, and I suspect that quite a few users were led to believe
the same thing.

Derick's proposal allows for those users to control the type of their
variables and allows for those who care about the content of their
variables more than their type to do that as well.

> It does not change any behavior - right now there's two sets of objects in
> PHP - primitive types and classes. Values of primitive types can be
> converted into another type, implicitly or explicitly, objects of classes
> can not.

As a PHP user, I have no such notion I'm afraid. From my point of
view, there's not two sets of objects, there's about ~8 types, PHP's
core functions and operators do not care too much about those types
and convert them internally. That's all the users see.

I'm not sure what you meant by "objects of classes can not [be
converted into another type]". Arrays can be cast as booleans (false
is empty, true otherwise), objects can be cast as arrays (properties
become keys) and strings to objects (with a single property called
"scalar", leaving everybody wondering what's going on there.)

TL;DR: I always thought PHP would help me control the type of my
variables instead of forcing my userland code to mirror PHP's internal
functions.

PS: I think I've just figured out what you meant by "conversion". Were
you talking about the internal conversion rules used by PHP's internal
functions? Are those described somewhere in the manual?

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

Re: [PHP-DEV] Strict typing

[Ilia Alshanetsky]

Sounds like a reasonable name change. PHP never really had
"type-hinting" since even array or Object type "hints" would throw out
any value that didn't precisely match the requested type by the
method/function declaration.

On Tue, Aug 10, 2010 at 8:53 PM, Stas Malyshev  wrote:
> Hi!
>
>> Might be the time to rename what we currently call "type hinting" then.
>> Because what we currently have is strict typing as well.
>
> Maybe. The term "hint" was inexact from the start, as hint means (Collins
> English Dictionary):
>
> 1. a suggestion or implication given in an indirect or subtle manner he
> dropped a hint
> 2. a helpful piece of advice or practical suggestion
> 3. a small amount; trace
>
> That's clearly not what is going on - there's nothing subtle or indirect
> there and there's not a suggestion - it's a strict and unequivocal
> definition of type expected for the function call.
>
> But with its use in 5.3 it didn't matter since it was clear what we are
> talking about and there was no possibility of confusion. Right now what we
> have is a classic strict typing, albeit not required for all places but
> f(int $f) in PHP would be the same as f(int i) in C, so calling them
> differently would only lead to confusion. Maybe we should have called it
> "parameter typing" or something like that from the start. It didn't seem
> important back then because everybody agreed what it means. Obviously it is
> no longer the case.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

Re: [PHP-DEV] Strict typing

[Stas Malyshev]

Hi!


Might be the time to rename what we currently call "type hinting" then.
Because what we currently have is strict typing as well.


Maybe. The term "hint" was inexact from the start, as hint means 
(Collins English Dictionary):


1. a suggestion or implication given in an indirect or subtle manner he 
dropped a hint

2. a helpful piece of advice or practical suggestion
3. a small amount; trace

That's clearly not what is going on - there's nothing subtle or indirect 
there and there's not a suggestion - it's a strict and unequivocal 
definition of type expected for the function call.


But with its use in 5.3 it didn't matter since it was clear what we are 
talking about and there was no possibility of confusion. Right now what 
we have is a classic strict typing, albeit not required for all places 
but f(int $f) in PHP would be the same as f(int i) in C, so calling them 
differently would only lead to confusion. Maybe we should have called it 
"parameter typing" or something like that from the start. It didn't seem 
important back then because everybody agreed what it means. Obviously it 
is no longer the case.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Stas Malyshev]

Hi!


First of all, I am talking about the typehinting syntax and mechanism
here. As Derick pointed out, current typehints are strict.


Talking about "strict" vs. "non-strict" for class types is meaningless. 
You can consider them non-strict if you want - they convert if the 
conversion is available, just like the rest of PHP, with only note that 
conversion is *never* available.
But it's just a semantic game because we are talking about different 
things here. Using the same syntax just confused you to think they are 
the same, but in PHP they are not. There are some languages where 
there's no primitive types or primitive types aren't different from 
classes - but PHP, for better or worse, as of now is not one of them.



Secondly, I don't support amalgaming userland with internal functions.
If I was to treat those internal functions as if they were written in
userland, I'd say that they don't use scalar typehints, specifically
for the reason you mentionned. Internal functions just typecast
whatever you throw at them, no question asked.


Again, it's just semantic games - you can call it "typehints" or not, 
your choice, but the fact is they did not fixate on the bitwise 
representation of the types - and we shouldn't start fixating on that 
now. They accept "1" when numeric value is needed, why can't you?



Again, I'm not talking about internal functions but typehinting. Now,
when a userland developer uses typehints it means they expect a
variable of a certain type to be passed. If they want typecasting,
Derick proposes a convenient way to do that.


That's exactly what is wrong with it - developer should NOT expect 
"variable of certain type to be passed" (if we are talking about 
primitive types), because PHP is not a strictly typed language, it's a 
dynamic language. There could be strictly typed language with PHP 
syntax, no problem, but that would a) require much more than just 
function parameters and b) not be PHP.



The current typehinting system does not typecast. Changing that
behaviour makes it ambiguous. It introduces a new behaviour grafted
onto the old mechanism and without a new syntax.


It does not change any behavior - right now there's two sets of objects 
in PHP - primitive types and classes. Values of primitive types can be 
converted into another type, implicitly or explicitly, objects of 
classes can not.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Victor Bolshov]

Having two similar syntaxes that work differently - would make the
situation even worse that it is now - I beleive. And I totally agree
with Rasmus - strict typed language mustnt be called PHP. (Just a poor
user's notice to all of you internals' geeks out there)

2010/8/11 Stas Malyshev :
> Hi!
>
>> 1. right now we *have* strict type checks for classes and arrays in the
>>    form of "classname" or "array"
>
> Because classes and arrays were never intechangeable types and there was
> never implicit or explicit conversion between SplRecursiveTreeIterator and
> Zend_Pdf_Generator - it doesn't even make sense to suggest it. There always
> was conversion between int and string or int and bool. These two things are
> completely different.
>
>> 2. the strict scalary type hint patch reuses this same syntax in the
>>    form of  to do the same thing in function arguments
>
> It's not a good thing. As I mentioned, primitive types and classes are very
> different in their use cases and established patterns in PHP. Primitive
> types are largely interchangeable, classes are not. (As for arrays, arrays
> really should be a class by their usage patterns etc. but for historic
> reasons... you know)
>
>> 3. we have casting type hints in the rest of the code in the form of
>>    "(int)".
>
> Just to make it simpler and less confusing, of course. It's nothing like
> language having two features that look almost exactly the same but work in
> different way, and using plenty of ()s is an added bonus for all Lisp fans
> out there.
>
>> Some people don't like strict typehints, but the syntax as it currently
>> is regarding type hints is *consistent*. Now, to allow both strict and
>> casting hints, the logical step seems to be, to give the weak typehint
>> advocates their tool as well:
>
> Calling something that works completely differently from all the established
> patterns of PHP - like internal functions, etc. - "*consistent*" requires
> totally new definition of this word.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
С уважением,
Виктор

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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Stas Malyshev]

Hi!


1. right now we *have* strict type checks for classes and arrays in the
form of "classname" or "array"


Because classes and arrays were never intechangeable types and there was 
never implicit or explicit conversion between SplRecursiveTreeIterator 
and Zend_Pdf_Generator - it doesn't even make sense to suggest it. There 
always was conversion between int and string or int and bool. These two 
things are completely different.



2. the strict scalary type hint patch reuses this same syntax in the
form of  to do the same thing in function arguments


It's not a good thing. As I mentioned, primitive types and classes are 
very different in their use cases and established patterns in PHP. 
Primitive types are largely interchangeable, classes are not. (As for 
arrays, arrays really should be a class by their usage patterns etc. but 
for historic reasons... you know)



3. we have casting type hints in the rest of the code in the form of
"(int)".


Just to make it simpler and less confusing, of course. It's nothing like 
language having two features that look almost exactly the same but work 
in different way, and using plenty of ()s is an added bonus for all Lisp 
fans out there.



Some people don't like strict typehints, but the syntax as it currently
is regarding type hints is *consistent*. Now, to allow both strict and
casting hints, the logical step seems to be, to give the weak typehint
advocates their tool as well:


Calling something that works completely differently from all the 
established patterns of PHP - like internal functions, etc. - 
"*consistent*" requires totally new definition of this word.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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