[PHP-DEV] Scalar type hinting

Following the John Crenshaw proposed terminology:
> - "Strict Typing" means the super strict old C style typing that has been
proven to be ridiculous in this environment because of the obvious problems
inherent in the fact that almost every input is a string.
> - "Weak Typing" means types in the same sense that the PHP documentation
uses types (for example, the docs indicate substr(string, integer), and
substr(12345, "2") == "345".)
> - "No Scalar Typing" should be used to indicate the current system (where
there is no provision for hinting at scalar types.)

Once this discussion comes together a little bit more and we have at least
a vague-ish idea what direction we're moving in, I'll also go ahead and
create an RFC as well so we have a conceptual product to build on.

> Hi,
>
> I create a new thread to discuss about Scalar type hinting.
>
> Following the John Crenshaw proposed terminology:
> > - "Strict Typing" means the super strict old C style typing that has
> been proven to be ridiculous in this environment because of the obvious
> problems inherent in the fact that almost every input is a string.
> > - "Weak Typing" means types in the same sense that the PHP documentation
> uses types (for example, the docs indicate substr(string, integer), and
> substr(12345, "2") == "345".)
> > - "No Scalar Typing" should be used to indicate the current system
> (where there is no provision for hinting at scalar types.)
>
> Previous weak typing proposal could be found here :
> https://wiki.php.net/rfc/typechecking
>
> I have no rights to edit the wiki and make a summary of previous
> arguments, so if someone could create it...
>
>
> --
> Samuel DEAL
> samuel.deal@gmail.com
>
>

What I've wanted for awhile, but don't know what the implementation
problems would be, is to allow for two new variable types to solve
this problem - Strict and tolerant variables. Both of these must be
declared formally (otherwise PHP assumes scalar) and the datatype must
be included. The syntax

// A tolerant variable.
integer $a = 3;

// A strict variable
strict integer $b = 2;

Tolerant variables silently cast values to their declared datatype.
Maybe they should raise E_NOTICE?
Strict variables refuse to be assigned a value with an incorrect
datatype. Raise E_WARNING?

A strict function would have the current behavior of kicking a warning
when the type hinting fails. Otherwise, functions should be tolerant
-

function foo ( integer $a, string $b, $c ) {}

strict function foo ( integer $a, $string $b, $c ) {}

A function parameter without a datatype would be ignored.

This does open the door to function overloading, but the engine
problems of this are well documented and have been discussed. Still,
I don't think it's a bad thing to have a syntax that allows for method
overloading in the future.

On Sun, Feb 26, 2012 at 10:52 PM, Kris Craig <[email protected]> wrote:
> I'll try to find some time tonight to create that for ya.
>
> Once this discussion comes together a little bit more and we have at least
> a vague-ish idea what direction we're moving in, I'll also go ahead and
> create an RFC as well so we have a conceptual product to build on.
>
> --Kris
>
>
> On Sun, Feb 26, 2012 at 6:27 PM, Samuel Deal <[email protected]> wrote:
>
>> Hi,
>>
>> I create a new thread to discuss about Scalar type hinting.
>>
>> Following the John Crenshaw proposed terminology:
>> > - "Strict Typing" means the super strict old C style typing that has
>> been proven to be ridiculous in this environment because of the obvious
>> problems inherent in the fact that almost every input is a string.
>> > - "Weak Typing" means types in the same sense that the PHP documentation
>> uses types (for example, the docs indicate substr(string, integer), and
>> substr(12345, "2") == "345".)
>> > - "No Scalar Typing" should be used to indicate the current system
>> (where there is no provision for hinting at scalar types.)
>>
>> Previous weak typing proposal could be found here :
>> https://wiki.php.net/rfc/typechecking
>>
>> I have no rights to edit the wiki and make a summary of previous
>> arguments, so if someone could create it...
>>
>>
>> --
>> Samuel DEAL
>> samuel.deal@gmail.com
>>
>>

As I remember, there was never a discussion about adding type hints
when declaring vars. The original discussion was and is about
finishing the support for type hints because PHP allready has
typehinting for arrays and objects. Additionaly there was launched a
discussion about function/method return typehints.
I do think the variable declaration type hints are pointless because
variables are chaning their types on the fly. But mostly it will
polute current discussion even more and adds a whole new super-global
level of thinking through and implementation details. It's just too
much.
We had type hinting discussions for a few years now and never reached
any conclusion and patches that have been made still had lots of
problems. We should really focus on param type hints and maybe on
return type hints for now and see where it takes us.

Because the new thread has been created, I will leave my arguments
here for the record.

I, as a user land developer, would like the weak type hinting, which
takes care of transparent conversions where no data loss is happening.
I would like to get a E_NOTICE or E_WARNING when some loss is
happening (for example I pass a string "aaa", but function expects an
integer or double. It would convert it to 1, but also will emit the
warning/notice for me to inspect what went wrong). And fatal errors on
serious type miss match like it is now done with objects and arrays.
This way is 100% backwards compatible, it does not add a ton of new
rules to remember when write code and is based on the mechanics PHP
already has, just extended a little. Same goes for the return type
hints.
The only case I do not remember being discussed in detail (maybe it
was and I somehow missed that part) is when we accept (and return for
return type hints) a mixed type param. Is it somehow described or we
just leave out the type hints at all. It's not so rare to see
something like this: function do(string $str = null). By logic it
accepts 2 types - null and string, but type hint says it accepts only
string and doing a call do(null) should work despite the type hint.

PHP is no strickt-typed language. Changing this is a massive change, if
you want to go there: There are plenty of other languages.

If you want this to be an optional feature:
a) It's not optional (one has to maintain code written by others, uses
libraries, frameworks, ...)
b) It causes a hell lot of trouble with copy-on-write. going from
fixed-typed to non-fixed-typed variables (in a funciton call or
assignment or such) will always have to cause a copy. This will hurt the
performance in hardly predictable ways.

johannes

On Mon, 2012-02-27 at 09:29 -0500, Michael Morris wrote:
> What I've wanted for awhile, but don't know what the implementation
> problems would be, is to allow for two new variable types to solve
> this problem - Strict and tolerant variables. Both of these must be
> declared formally (otherwise PHP assumes scalar) and the datatype must
> be included. The syntax
>
> // A tolerant variable.
> integer $a = 3;
>
> // A strict variable
> strict integer $b = 2;
>
> Tolerant variables silently cast values to their declared datatype.
> Maybe they should raise E_NOTICE?
> Strict variables refuse to be assigned a value with an incorrect
> datatype. Raise E_WARNING?
>
> A strict function would have the current behavior of kicking a warning
> when the type hinting fails. Otherwise, functions should be tolerant
> -
>
> function foo ( integer $a, string $b, $c ) {}
>
> strict function foo ( integer $a, $string $b, $c ) {}
>
> A function parameter without a datatype would be ignored.
>
> This does open the door to function overloading, but the engine
> problems of this are well documented and have been discussed. Still,
> I don't think it's a bad thing to have a syntax that allows for method
> overloading in the future.
>
> On Sun, Feb 26, 2012 at 10:52 PM, Kris Craig <[email protected]> wrote:
> > I'll try to find some time tonight to create that for ya.
> >
> > Once this discussion comes together a little bit more and we have at least
> > a vague-ish idea what direction we're moving in, I'll also go ahead and
> > create an RFC as well so we have a conceptual product to build on.
> >
> > --Kris
> >
> >
> > On Sun, Feb 26, 2012 at 6:27 PM, Samuel Deal <[email protected]> wrote:
> >
> >> Hi,
> >>
> >> I create a new thread to discuss about Scalar type hinting.
> >>
> >> Following the John Crenshaw proposed terminology:
> >> > - "Strict Typing" means the super strict old C style typing that has
> >> been proven to be ridiculous in this environment because of the obvious
> >> problems inherent in the fact that almost every input is a string.
> >> > - "Weak Typing" means types in the same sense that the PHP documentation
> >> uses types (for example, the docs indicate substr(string, integer), and
> >> substr(12345, "2") == "345".)
> >> > - "No Scalar Typing" should be used to indicate the current system
> >> (where there is no provision for hinting at scalar types.)
> >>
> >> Previous weak typing proposal could be found here :
> >> https://wiki.php.net/rfc/typechecking
> >>
> >> I have no rights to edit the wiki and make a summary of previous
> >> arguments, so if someone could create it...
> >>
> >>
> >> --
> >> Samuel DEAL
> >> samuel.deal@gmail.com
> >>
> >>
>

> Hi,
>
> PHP is no strickt-typed language. Changing this is a massive change, if
> you want to go there: There are plenty of other languages.
>
> If you want this to be an optional feature:
> a) It's not optional (one has to maintain code written by others, uses
> libraries, frameworks, ...)
> b) It causes a hell lot of trouble with copy-on-write. going from
> fixed-typed to non-fixed-typed variables (in a funciton call or
> assignment or such) will always have to cause a copy. This will hurt the
> performance in hardly predictable ways.
>
> johannes
>

Big +1 from me. Thanks for the post Johannes!

It makes sense to have a type hint for the different type of data
structures.
1) array
2) object ( class name for OOP ).

The scalar values (int, string, double) are type-less, flexible and should
remain that way. If you want strict typehinting then move to another
language.

But what about optional weak (auto-convert) type hints? They should
make life if not easier, definitively a little richer when writing
API's and internal stuff, where some additional strictness and
warnings generated make sense.
And it definitively makes IDE's more happy and easier to generate
PHPDoc blocks, not to mention Reflection stuff can be added and find
it's uses pretty fast.
I see it as anonymous functions - you can definitively live without
them, but they are wonderful and made some functionality better (for
example Yii Framework used eval for many things and with PHP 5.3 we
just started to use anonymous functions instead - the support was
build in before the 5.3 even started) - same I see happening here in
the future.
But yes, any major work that changes things a lot will just make a
mess and many BC issues.

On 27/02/12 17:19, Richard Lynch wrote:
> PRESUMPTION:
>
> *ANY* strict datatype could also be NULL, to represent a failure
> condition...
>
> Otherwise, when you are out of RAM:
> strict $o = new Object(); //violates strict, because Object HAS to be
> NULL, as there is no RAM left for it to be an object.
Uh? No. You would get a fatal error because PHP exceeded maximum
allowed memory.

On 27/02/12 16:47, Paul Dragoonis wrote:
> 2012/2/27 Johannes Schlüter <[email protected]>
>> Hi,
>>
>> PHP is no strickt-typed language. Changing this is a massive change, if
>> you want to go there: There are plenty of other languages.
>>
>> If you want this to be an optional feature:
>> a) It's not optional (one has to maintain code written by others, uses
>> libraries, frameworks, ...)
>> b) It causes a hell lot of trouble with copy-on-write. going from
>> fixed-typed to non-fixed-typed variables (in a funciton call or
>> assignment or such) will always have to cause a copy. This will hurt the
>> performance in hardly predictable ways.
>>
>> johannes
>>
> Big +1 from me. Thanks for the post Johannes!
I also agree with Johannes, that would be too much trouble.

> It makes sense to have a type hint for the different type of data
> structures.
> 1) array
> 2) object ( class name for OOP ).
>
> The scalar values (int, string, double) are type-less, flexible and should
> remain that way. If you want strict typehinting then move to another
> language.
But I disagree with you in that string is always a scalar.

int and double being the same thing, that's ok, even though I usually have
to deal and verify for just natural numbers, but the consideration that it's
a variable of numeric type which could hold many types of numbers is
acceptable. Both are also implemented inside the zval.

Now strings. There are two different kinds of strings.
The first one $age = $_POST['age'] is the kind of string that you want to
treat as a number. And that's fine.

But you also have $name = $_POST['name'] // 'John Doe' which is wrong
to treat as a the same as $age.

---
Hello, I see you were born in <?= $thisyear - $name ?>. You look older.

> So the official response is "get lost"?
>
>
no, it is: "come back after you did your homework, and you can provide new
arguments to the discussion"

> I don't know about the internals implications. But from an external
> API standpoint I see no problem in allowing programmers who want to
> strictly enforce a variable's datatype to do so. Legacy code would
> not be affected unless it was trying to use the new reserved word
> "strict"
>
>
it was discussed before, strict typing tends to be "viral", in the sense
that the developer using a lib which enforces method signatures using type
hinting can either:
- write a lot of boiler plate code to make sure that he/she is passing the
expected types (notice that strict typing would pass that burden to the api
consumer, which is against the Generous on input, strict on output
paradigm, plus it would generate much more work, as there are always more
consumers than producers)
- or simply passing those requirements up in the call chain, which is less
work, but affects even more code, and in the end, turns the whole app into
strict typing.

>
>
> Now strings. There are two different kinds of strings.
> The first one $age = $_POST['age'] is the kind of string that you want to
> treat as a number. And that's fine.
>
> But you also have $name = $_POST['name'] // 'John Doe' which is wrong
> to treat as a the same as $age.
>
>
php doesn't have the necessary information to tell whether your input
variable is a number, or only looks like a number.
how would you define what is an int? what type would the following input
variables have?
- "1"
- "1.1"
- "1.0"
- ".5"
- "0777"

I think it is better to populate everything as string, and let the
application developer to parse the inputs as he knows what should they
represent.

Btw. there was a discussion about raising a warning (somebody even
suggested creating an E_TYPE level) when data loss occurs on a type
juggling.
I would support that, as people tend to be surprised when they realize the
first time that 123 == '123 apples' evaluates to true in php.

Discussed to death. Yet only one time before (discussing a specific patch)....

And the opponents still said no...

There were also quite a few problems identified with scalar hinting
and auto-casting vs strict erroring. However, there were also
solutions proposed to nearly each and every one of them.

And the opponents still said no...

It has been brought up time and time again. Solutions have been
proposed which have no fundimental issues (inconsistencies,
problematic operations - such as references, etc)...

And the opponents instead said "this has been discussed to death, no"...

Please can you stop saying "this has been discussed to death". To be
frank, don't stop the discussion because you don't like the idea. It
has been discussed to death. But the discussion has only really ever
involved people who are for it. The opponents by and large have used
two arguments: "It has been discussed already, so no" and "don't make
PHP into Java".

There has been some discussion of technical merit and problem
resolution by opponents, but finding it is VERY difficult among all
the down trodding commentary.

So let me make a plea:

If you don't like this feature, and you can explain from a TECHNICAL
perspective why, please do so! If you don't like the feature, and are
going to lean on "It's not Java", or "We've discussed this to death
already", please don't...

And to be fair: "and you can provide new arguments to the discussion"
has already happened quite a bit (dating back the past 5 years), but
those arguments were ignored or overruled for political reasons.

Anthony

On Mon, Feb 27, 2012 at 11:55 AM, Ferenc Kovacs <[email protected]> wrote:
> On Mon, Feb 27, 2012 at 5:16 PM, Michael Morris <[email protected]>wrote:
>
>> So the official response is "get lost"?
>>
>>
> no, it is: "come back after you did your homework, and you can provide new
> arguments to the discussion"
>
>
>
>> I don't know about the internals implications. But from an external
>> API standpoint I see no problem in allowing programmers who want to
>> strictly enforce a variable's datatype to do so. Legacy code would
>> not be affected unless it was trying to use the new reserved word
>> "strict"
>>
>>
> it was discussed before, strict typing tends to be "viral", in the sense
> that the developer using a lib which enforces method signatures using type
> hinting can either:
> - write a lot of boiler plate code to make sure that he/she is passing the
> expected types (notice that strict typing would pass that burden to the api
> consumer, which is against the Generous on input, strict on output
> paradigm, plus it would generate much more work, as there are always more
> consumers than producers)
> - or simply passing those requirements up in the call chain, which is less
> work, but affects even more code, and in the end, turns the whole app into
> strict typing.
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu

Remember you're dealing with the internals list. :)
I kind of like the idea of having long proper discussions on a
particular topic. But let's face it, that's an utopic view (at best)!

Even if optional, and even if backwards compatible, there are a number
of things that will be quite hard to change, ranging from "it's very
difficult/impossible to implement properly", to "this isn't the PHP
way"...

Guys, seriously. Some of these responses have been downright rude and
inappropriate for a constructive dialogue. Please do not pollute this
thread with cliche, "Just find another language and get out!" posts. It
doesn't add anything to the conversation and instead just creates needless
anger and animosity. It's immature and just makes it look like we're
incapable of having a rational discussion.

So, let me outline a list of "arguments" that will carry ZERO weight on
this thread:

- "If you don't like PHP as it is, goto Java (or some other language)!"
- "We've already talked about this before. Therefore, we must never
speak of it again."
- "This is impossible. Why? Because I said so. You want evidence?
Fuck you."
- "But this would require significant changes to the core source code!
We'd never be able to find enough sacrificial penguins to appease the gods!"
- "Anyone who likes this idea is either stupid or not a 'true' PHP
developer."
- "If you disagree with me, it means you haven't done your homework
because I'm always right."
- "Strict typing would break everything! What? You're not talking
about C-like strict typing? Sorry, I didn't catch that. Strict typing
would break everything!...."
- "I don't care if you've already countered my argument. I'll just keep
repeating myself as if you didn't."

Variations of the above statements have been posted ad nauseum. They're
all based on logical fallacies and are not constructive.

I'm putting this out there: If anyone posts one or more of the above
arguments yet again on this topic, I will personally extract one of your
kidneys and sell it to a questionable "dog food" company in Shanghai. I
will then openly mock your intellectual laziness and encourage people to
ignore you. ;P

I'd love to prove Daniel wrong, but I think he may be on to something....
:\

> > no, it is: "come back after you did your homework, and you can provide
> new
> > arguments to the discussion"
>
>
> To be completely fair, I did homework on this. I went back to 2000 on
> marc.info's archives and read almost all of the 400 posts matching the
> search http://marc.info/?l=php-internals&w=2&r=13&s=strict+typing&q=b
> and a bunch of the posts on
> http://marc.info/?l=php-internals&w=2&r=54&s=type+hinting&q=b
>
> The vast majority of what I found were quite good arguments for
> including the feature. I found quite a bit of "this was discussed to
> death, do your homework and provide new arguments". What's odd, is
> that one of the earliest on-topic threads that I found (2007:
> http://marc.info/?l=php-internals&m=119514660125258&w=2 ) had this as
> the third reply. The only on-topic discussion that I found prior to
> that was in 2006 (almost exactly 1 year prior:
> http://marc.info/?l=php-internals&m=116257685415135&w=2 ).
>
> Discussed to death. Yet only one time before (discussing a specific
> patch)...
>
> And the opponents still said no...
>
> There were also quite a few problems identified with scalar hinting
> and auto-casting vs strict erroring. However, there were also
> solutions proposed to nearly each and every one of them.
>
> And the opponents still said no...
>
> It has been brought up time and time again. Solutions have been
> proposed which have no fundimental issues (inconsistencies,
> problematic operations - such as references, etc)...
>
> And the opponents instead said "this has been discussed to death, no"...
>
> Please can you stop saying "this has been discussed to death". To be
> frank, don't stop the discussion because you don't like the idea. It
> has been discussed to death. But the discussion has only really ever
> involved people who are for it. The opponents by and large have used
> two arguments: "It has been discussed already, so no" and "don't make
> PHP into Java".
>
> There has been some discussion of technical merit and problem
> resolution by opponents, but finding it is VERY difficult among all
> the down trodding commentary.
>
> So let me make a plea:
>
> If you don't like this feature, and you can explain from a TECHNICAL
> perspective why, please do so! If you don't like the feature, and are
> going to lean on "It's not Java", or "We've discussed this to death
> already", please don't...
>
>
>
> And to be fair: "and you can provide new arguments to the discussion"
> has already happened quite a bit (dating back the past 5 years), but
> those arguments were ignored or overruled for political reasons.
>
>
> Anthony
>
>
> On Mon, Feb 27, 2012 at 11:55 AM, Ferenc Kovacs <t[email protected]> wrote:
> > On Mon, Feb 27, 2012 at 5:16 PM, Michael Morris <[email protected]
> >wrote:
> >
> >> So the official response is "get lost"?
> >>
> >>
> > no, it is: "come back after you did your homework, and you can provide
> new
> > arguments to the discussion"
> >
> >
> >
> >> I don't know about the internals implications. But from an external
> >> API standpoint I see no problem in allowing programmers who want to
> >> strictly enforce a variable's datatype to do so. Legacy code would
> >> not be affected unless it was trying to use the new reserved word
> >> "strict"
> >>
> >>
> > it was discussed before, strict typing tends to be "viral", in the sense
> > that the developer using a lib which enforces method signatures using
> type
> > hinting can either:
> > - write a lot of boiler plate code to make sure that he/she is passing
> the
> > expected types (notice that strict typing would pass that burden to the
> api
> > consumer, which is against the Generous on input, strict on output
> > paradigm, plus it would generate much more work, as there are always more
> > consumers than producers)
> > - or simply passing those requirements up in the call chain, which is
> less
> > work, but affects even more code, and in the end, turns the whole app
> into
> > strict typing.
> >
> > --
> > Ferenc Kovács
> > @Tyr43l - http://tyrael.hu
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

On Mon, February 27, 2012 10:45 am, Ángel González wrote:
> On 27/02/12 17:19, Richard Lynch wrote:
>> PRESUMPTION:
>>
>> *ANY* strict datatype could also be NULL, to represent a failure
>> condition...
>>
>> Otherwise, when you are out of RAM:
>> strict $o = new Object(); //violates strict, because Object HAS to
>> be
>> NULL, as there is no RAM left for it to be an object.
> Uh? No. You would get a fatal error because PHP exceeded maximum
> allowed memory.

You are correct.

I'd have to come up with some OTHER scenario not involving fatal
error, such as:

strict $db = new DB();

and your database being down, unavailable, or connection parameters
being wrong.

The principle remains.

You probably still want $db to be NULL in that situation, rather than
an unusable DB object.

Otherwise, you'll have to write a lot more sanity checking code
elsewhere, which is what you are trying to avoid in the first place...

Or, perhaps not.

Perhaps you really do want this case to just plain bomb out with a
failure that the $db is not strictly an object, with no recourse to
try again, or deal with the error in application logic...

Now, to rewind a bit past the latest chunk of "I hate this idea" posts....

I'd like to suggest a new term: "strong".

This term would be similar to "weak", except with a few key differences:

- Weak would behave very much like Arvids suggested in his earlier post;
i.e. if the variable is an integer but you pass a string (like "aaa") to
it, a warning would be thrown and PHP would attempt to convert it (i.e. it
would become 1).
- Strong, on the other hand, would throw a fatal error if you attempted
to pass an incompatible value to an array. Or, to put it another way, if
the "converted" value does not match the original value. For example, if
we're assigning "aaa" to an integer, that would convert to 1; and, since
"1" != "aaa", a fatal error would be thrown. On the other hand, if you
were to pass the string "1" to that integer variable, it would convert to
1; and, since "1" == 1, there wouldn't be a problem.
- In both instances, if the converted value matches the original (i.e.
"1" == 1), no warning error would be displayed. Should it perhaps display
a notice though? Or no error at all? I can think of reasonable arguments
on both sides of that question.

This new term would also make it easier for us to avoid using the term
"strict," which would explode even in the case of "1" == 1.

Whether this should be done at the function level, the variable level, or
both is an open-ended question.

> +1 what Anthony said.
>
> Guys, seriously. Some of these responses have been downright rude and
> inappropriate for a constructive dialogue. Please do not pollute this
> thread with cliche, "Just find another language and get out!" posts. It
> doesn't add anything to the conversation and instead just creates needless
> anger and animosity. It's immature and just makes it look like we're
> incapable of having a rational discussion.
>
> So, let me outline a list of "arguments" that will carry ZERO weight on
> this thread:
>
> - "If you don't like PHP as it is, goto Java (or some other language)!"
> - "We've already talked about this before. Therefore, we must never
> speak of it again."
> - "This is impossible. Why? Because I said so. You want evidence?
> Fuck you."
> - "But this would require significant changes to the core source
> code! We'd never be able to find enough sacrificial penguins to appease
> the gods!"
> - "Anyone who likes this idea is either stupid or not a 'true' PHP
> developer."
> - "If you disagree with me, it means you haven't done your homework
> because I'm always right."
> - "Strict typing would break everything! What? You're not talking
> about C-like strict typing? Sorry, I didn't catch that. Strict typing
> would break everything!...."
> - "I don't care if you've already countered my argument. I'll just
> keep repeating myself as if you didn't."
>
>
> Variations of the above statements have been posted ad nauseum. They're
> all based on logical fallacies and are not constructive.
>
> I'm putting this out there: If anyone posts one or more of the above
> arguments yet again on this topic, I will personally extract one of your
> kidneys and sell it to a questionable "dog food" company in Shanghai. I
> will then openly mock your intellectual laziness and encourage people to
> ignore you. ;P
>
>
> I'd love to prove Daniel wrong, but I think he may be on to something....
> :\
>
> --Kris
>
>
>
> On Mon, Feb 27, 2012 at 9:38 AM, Anthony Ferrara <[email protected]>wrote:
>
>> > no, it is: "come back after you did your homework, and you can provide
>> new
>> > arguments to the discussion"
>>
>>
>> To be completely fair, I did homework on this. I went back to 2000 on
>> marc.info's archives and read almost all of the 400 posts matching the
>> search http://marc.info/?l=php-internals&w=2&r=13&s=strict+typing&q=b
>> and a bunch of the posts on
>> http://marc.info/?l=php-internals&w=2&r=54&s=type+hinting&q=b
>>
>> The vast majority of what I found were quite good arguments for
>> including the feature. I found quite a bit of "this was discussed to
>> death, do your homework and provide new arguments". What's odd, is
>> that one of the earliest on-topic threads that I found (2007:
>> http://marc.info/?l=php-internals&m=119514660125258&w=2 ) had this as
>> the third reply. The only on-topic discussion that I found prior to
>> that was in 2006 (almost exactly 1 year prior:
>> http://marc.info/?l=php-internals&m=116257685415135&w=2 ).
>>
>> Discussed to death. Yet only one time before (discussing a specific
>> patch)...
>>
>> And the opponents still said no...
>>
>> There were also quite a few problems identified with scalar hinting
>> and auto-casting vs strict erroring. However, there were also
>> solutions proposed to nearly each and every one of them.
>>
>> And the opponents still said no...
>>
>> It has been brought up time and time again. Solutions have been
>> proposed which have no fundimental issues (inconsistencies,
>> problematic operations - such as references, etc)...
>>
>> And the opponents instead said "this has been discussed to death, no"...
>>
>> Please can you stop saying "this has been discussed to death". To be
>> frank, don't stop the discussion because you don't like the idea. It
>> has been discussed to death. But the discussion has only really ever
>> involved people who are for it. The opponents by and large have used
>> two arguments: "It has been discussed already, so no" and "don't make
>> PHP into Java".
>>
>> There has been some discussion of technical merit and problem
>> resolution by opponents, but finding it is VERY difficult among all
>> the down trodding commentary.
>>
>> So let me make a plea:
>>
>> If you don't like this feature, and you can explain from a TECHNICAL
>> perspective why, please do so! If you don't like the feature, and are
>> going to lean on "It's not Java", or "We've discussed this to death
>> already", please don't...
>>
>>
>>
>> And to be fair: "and you can provide new arguments to the discussion"
>> has already happened quite a bit (dating back the past 5 years), but
>> those arguments were ignored or overruled for political reasons.
>>
>>
>> Anthony
>>
>>
>> On Mon, Feb 27, 2012 at 11:55 AM, Ferenc Kovacs <[email protected]> wrote:
>> > On Mon, Feb 27, 2012 at 5:16 PM, Michael Morris <[email protected]
>> >wrote:
>> >
>> >> So the official response is "get lost"?
>> >>
>> >>
>> > no, it is: "come back after you did your homework, and you can provide
>> new
>> > arguments to the discussion"
>> >
>> >
>> >
>> >> I don't know about the internals implications. But from an external
>> >> API standpoint I see no problem in allowing programmers who want to
>> >> strictly enforce a variable's datatype to do so. Legacy code would
>> >> not be affected unless it was trying to use the new reserved word
>> >> "strict"
>> >>
>> >>
>> > it was discussed before, strict typing tends to be "viral", in the sense
>> > that the developer using a lib which enforces method signatures using
>> type
>> > hinting can either:
>> > - write a lot of boiler plate code to make sure that he/she is passing
>> the
>> > expected types (notice that strict typing would pass that burden to the
>> api
>> > consumer, which is against the Generous on input, strict on output
>> > paradigm, plus it would generate much more work, as there are always
>> more
>> > consumers than producers)
>> > - or simply passing those requirements up in the call chain, which is
>> less
>> > work, but affects even more code, and in the end, turns the whole app
>> into
>> > strict typing.
>> >
>> > --
>> > Ferenc Kovács
>> > @Tyr43l - http://tyrael.hu
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>

On Mon, February 27, 2012 11:38 am, Anthony Ferrara wrote:
> Discussed to death. Yet only one time before (discussing a specific
> patch)...

Did you go back to the old, old, old PHP list (and was it PHP-dev back
then?), before it split into php-general and php-internals and php-*,
back when there weren't enough users to warrant more than two lists?

You may find more fruitful results there, I think.

Or not.

Did you check the wiki and RFCs that came out of those discussions?

Those are the places where the really serious proposals with patches
developed after the mailing list wrangling.

They all failed, in the end, but those are the ones that actually got
taken seriously, because they had enough specificity to discuss for or
against for technical merit.

The idea has always always had some technical merit. The
implementation, however, has always failed.

The very strict typing usually failed quickly.

The not so strict typing either failed after a lot of effort, and edge
cases kept cropping up, or ended up being so weak as to not provide
any additional value over the original dynamic typing.

The patches are out there. The conclusions and technical issues are
out there. They may be lost in the sea of flame-wars, but they do
exist.

> If you don't like this feature, and you can explain from a TECHNICAL
> perspective why, please do so! If you don't like the feature, and are
> going to lean on "It's not Java", or "We've discussed this to death
> already", please don't...

Stas has already stated that you can't do what you want and have it
mean anything without changing the very nature of PHP.

I said the same, poorly, and invite you to TRY with a patch instead of
discussing it endlessly here.

> And to be fair: "and you can provide new arguments to the discussion"
> has already happened quite a bit (dating back the past 5 years), but
> those arguments were ignored or overruled for political reasons.

> Now, to rewind a bit past the latest chunk of "I hate this idea" posts.....
>
> I'd like to suggest a new term: "strong".
>
> This term would be similar to "weak", except with a few key differences:
>
> - Weak would behave very much like Arvids suggested in his earlier
> post; i.e. if the variable is an integer but you pass a string (like "aaa")
> to it, a warning would be thrown and PHP would attempt to convert it (i.e.
> it would become 1).
> - Strong, on the other hand, would throw a fatal error if you
> attempted to pass an incompatible value to an array. Or, to put it another
> way, if the "converted" value does not match the original value. For
> example, if we're assigning "aaa" to an integer, that would convert to 1;
> and, since "1" != "aaa", a fatal error would be thrown. On the other hand,
> if you were to pass the string "1" to that integer variable, it would
> convert to 1; and, since "1" == 1, there wouldn't be a problem.
> - In both instances, if the converted value matches the original (i.e.
> "1" == 1), no warning error would be displayed. Should it perhaps display
> a notice though? Or no error at all? I can think of reasonable arguments
> on both sides of that question.
>
> This new term would also make it easier for us to avoid using the term
> "strict," which would explode even in the case of "1" == 1.
>
> Whether this should be done at the function level, the variable level, or
> both is an open-ended question.
>
>
> Some possible examples of how this would look:
>
> weak int $i = "aaa"; // Converts to 1 and throws a warning.
> strong int $ii = "aaa"; // Throws a fatal error.
> weak int $i = "1"; // Converts to 1.
> strong int $ii = "1"; // Converts to 1.
>
>
> --Kris
>
>
>
> On Mon, Feb 27, 2012 at 10:53 AM, Kris Craig <[email protected]> wrote:
>
>> +1 what Anthony said.
>>
>> Guys, seriously. Some of these responses have been downright rude and
>> inappropriate for a constructive dialogue. Please do not pollute this
>> thread with cliche, "Just find another language and get out!" posts. It
>> doesn't add anything to the conversation and instead just creates needless
>> anger and animosity. It's immature and just makes it look like we're
>> incapable of having a rational discussion.
>>
>> So, let me outline a list of "arguments" that will carry ZERO weight on
>> this thread:
>>
>> - "If you don't like PHP as it is, goto Java (or some other
>> language)!"
>> - "We've already talked about this before. Therefore, we must never
>> speak of it again."
>> - "This is impossible. Why? Because I said so. You want evidence?
>> Fuck you."
>> - "But this would require significant changes to the core source
>> code! We'd never be able to find enough sacrificial penguins to appease
>> the gods!"
>> - "Anyone who likes this idea is either stupid or not a 'true' PHP
>> developer."
>> - "If you disagree with me, it means you haven't done your homework
>> because I'm always right."
>> - "Strict typing would break everything! What? You're not talking
>> about C-like strict typing? Sorry, I didn't catch that. Strict typing
>> would break everything!...."
>> - "I don't care if you've already countered my argument. I'll just
>> keep repeating myself as if you didn't."
>>
>>
>> Variations of the above statements have been posted ad nauseum. They're
>> all based on logical fallacies and are not constructive.
>>
>> I'm putting this out there: If anyone posts one or more of the above
>> arguments yet again on this topic, I will personally extract one of your
>> kidneys and sell it to a questionable "dog food" company in Shanghai. I
>> will then openly mock your intellectual laziness and encourage people to
>> ignore you. ;P
>>
>>
>> I'd love to prove Daniel wrong, but I think he may be on to
>> something.... :\
>>
>> --Kris
>>
>>
>>
>> On Mon, Feb 27, 2012 at 9:38 AM, Anthony Ferrara <[email protected]>wrote:
>>
>>> > no, it is: "come back after you did your homework, and you can provide
>>> new
>>> > arguments to the discussion"
>>>
>>>
>>> To be completely fair, I did homework on this. I went back to 2000 on
>>> marc.info's archives and read almost all of the 400 posts matching the
>>> search http://marc.info/?l=php-internals&w=2&r=13&s=strict+typing&q=b
>>> and a bunch of the posts on
>>> http://marc.info/?l=php-internals&w=2&r=54&s=type+hinting&q=b
>>>
>>> The vast majority of what I found were quite good arguments for
>>> including the feature. I found quite a bit of "this was discussed to
>>> death, do your homework and provide new arguments". What's odd, is
>>> that one of the earliest on-topic threads that I found (2007:
>>> http://marc.info/?l=php-internals&m=119514660125258&w=2 ) had this as
>>> the third reply. The only on-topic discussion that I found prior to
>>> that was in 2006 (almost exactly 1 year prior:
>>> http://marc.info/?l=php-internals&m=116257685415135&w=2 ).
>>>
>>> Discussed to death. Yet only one time before (discussing a specific
>>> patch)...
>>>
>>> And the opponents still said no...
>>>
>>> There were also quite a few problems identified with scalar hinting
>>> and auto-casting vs strict erroring. However, there were also
>>> solutions proposed to nearly each and every one of them.
>>>
>>> And the opponents still said no...
>>>
>>> It has been brought up time and time again. Solutions have been
>>> proposed which have no fundimental issues (inconsistencies,
>>> problematic operations - such as references, etc)...
>>>
>>> And the opponents instead said "this has been discussed to death, no"....
>>>
>>> Please can you stop saying "this has been discussed to death". To be
>>> frank, don't stop the discussion because you don't like the idea. It
>>> has been discussed to death. But the discussion has only really ever
>>> involved people who are for it. The opponents by and large have used
>>> two arguments: "It has been discussed already, so no" and "don't make
>>> PHP into Java".
>>>
>>> There has been some discussion of technical merit and problem
>>> resolution by opponents, but finding it is VERY difficult among all
>>> the down trodding commentary.
>>>
>>> So let me make a plea:
>>>
>>> If you don't like this feature, and you can explain from a TECHNICAL
>>> perspective why, please do so! If you don't like the feature, and are
>>> going to lean on "It's not Java", or "We've discussed this to death
>>> already", please don't...
>>>
>>>
>>>
>>> And to be fair: "and you can provide new arguments to the discussion"
>>> has already happened quite a bit (dating back the past 5 years), but
>>> those arguments were ignored or overruled for political reasons.
>>>
>>>
>>> Anthony
>>>
>>>
>>> On Mon, Feb 27, 2012 at 11:55 AM, Ferenc Kovacs <[email protected]>
>>> wrote:
>>> > On Mon, Feb 27, 2012 at 5:16 PM, Michael Morris <
>>> [email protected]>wrote:
>>> >
>>> >> So the official response is "get lost"?
>>> >>
>>> >>
>>> > no, it is: "come back after you did your homework, and you can provide
>>> new
>>> > arguments to the discussion"
>>> >
>>> >
>>> >
>>> >> I don't know about the internals implications. But from an external
>>> >> API standpoint I see no problem in allowing programmers who want to
>>> >> strictly enforce a variable's datatype to do so. Legacy code would
>>> >> not be affected unless it was trying to use the new reserved word
>>> >> "strict"
>>> >>
>>> >>
>>> > it was discussed before, strict typing tends to be "viral", in the
>>> sense
>>> > that the developer using a lib which enforces method signatures using
>>> type
>>> > hinting can either:
>>> > - write a lot of boiler plate code to make sure that he/she is passing
>>> the
>>> > expected types (notice that strict typing would pass that burden to
>>> the api
>>> > consumer, which is against the Generous on input, strict on output
>>> > paradigm, plus it would generate much more work, as there are always
>>> more
>>> > consumers than producers)
>>> > - or simply passing those requirements up in the call chain, which is
>>> less
>>> > work, but affects even more code, and in the end, turns the whole app
>>> into
>>> > strict typing.
>>> >
>>> > --
>>> > Ferenc Kovács
>>> > @Tyr43l - http://tyrael.hu
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>

Now that you've voiced your opposition, can we please dedicate this topic
to discussing how this can be done? If you think we're wasting our time,
then ok; it's our time to waste. I'd be happy to take you up on your
challenge to try to implement this, but first we have to brainstorm what
exactly we'll be doing. And that'll be much easier if we don't have to
keep sifting through duplicate posts about why this is a bad idea. Let's
just set that aside for now so we can brainstorm.

On that note, I would like to direct everyone's attention to my last post
where I suggested a new "strong" concept.

> On Mon, February 27, 2012 11:38 am, Anthony Ferrara wrote:
> > Discussed to death. Yet only one time before (discussing a specific
> > patch)...
>
> Did you go back to the old, old, old PHP list (and was it PHP-dev back
> then?), before it split into php-general and php-internals and php-*,
> back when there weren't enough users to warrant more than two lists?
>
> You may find more fruitful results there, I think.
>
> Or not.
>
> Did you check the wiki and RFCs that came out of those discussions?
>
> Those are the places where the really serious proposals with patches
> developed after the mailing list wrangling.
>
> They all failed, in the end, but those are the ones that actually got
> taken seriously, because they had enough specificity to discuss for or
> against for technical merit.
>
> The idea has always always had some technical merit. The
> implementation, however, has always failed.
>
> The very strict typing usually failed quickly.
>
> The not so strict typing either failed after a lot of effort, and edge
> cases kept cropping up, or ended up being so weak as to not provide
> any additional value over the original dynamic typing.
>
> The patches are out there. The conclusions and technical issues are
> out there. They may be lost in the sea of flame-wars, but they do
> exist.
>
> > If you don't like this feature, and you can explain from a TECHNICAL
> > perspective why, please do so! If you don't like the feature, and are
> > going to lean on "It's not Java", or "We've discussed this to death
> > already", please don't...
>
> Stas has already stated that you can't do what you want and have it
> mean anything without changing the very nature of PHP.
>
> I said the same, poorly, and invite you to TRY with a patch instead of
> discussing it endlessly here.
>
> > And to be fair: "and you can provide new arguments to the discussion"
> > has already happened quite a bit (dating back the past 5 years), but
> > those arguments were ignored or overruled for political reasons.
>
> Write the proof of concept patch, please.
>
> Then we can discuss the technical merits or prove why it won't work.
>
> Otherwise, it really is an endless discussion of a dead horse.
>
> --
> brain cancer update:
> http://richardlynch.blogspot.com/search/label/brain%20tumor
> Donate:
>
> https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

> Now, to rewind a bit past the latest chunk of "I hate this idea" posts....
>
> I'd like to suggest a new term: "strong".
>
> This term would be similar to "weak", except with a few key differences:
>
> - Weak would behave very much like Arvids suggested in his earlier post;
> i.e. if the variable is an integer but you pass a string (like "aaa") to
> it, a warning would be thrown and PHP would attempt to convert it (i.e.
> it
> would become 1).
> - Strong, on the other hand, would throw a fatal error if you attempted
> to pass an incompatible value to an array. Or, to put it another way, if
> the "converted" value does not match the original value. For example, if
> we're assigning "aaa" to an integer, that would convert to 1; and, since
> "1" != "aaa", a fatal error would be thrown. On the other hand, if you
> were to pass the string "1" to that integer variable, it would convert to
> 1; and, since "1" == 1, there wouldn't be a problem.
> - In both instances, if the converted value matches the original (i.e.
> "1" == 1), no warning error would be displayed. Should it perhaps
> display
> a notice though? Or no error at all? I can think of reasonable
> arguments
> on both sides of that question.
>
> This new term would also make it easier for us to avoid using the term
> "strict," which would explode even in the case of "1" == 1.
>
> Whether this should be done at the function level, the variable level, or
> both is an open-ended question.
>
>
> Some possible examples of how this would look:
>
> weak int $i = "aaa"; // Converts to 1 and throws a warning.
> strong int $ii = "aaa"; // Throws a fatal error.
> weak int $i = "1"; // Converts to 1.
> strong int $ii = "1"; // Converts to 1.
>
>
> --Kris
>
>
Maybe this discussion should start from the end of the last discussion on
non-strict type hints, where really smart people came up with some options
to handle the conversion:

The RFC talks about throwing E_STRICT or E_FATAL, and has a couple of
options for a matrix of conversion rules.

I don't think we need another name for weak type hints, since the name
covers anything less than strict, and anything more than none. There's been
enough confusion about the names of things without adding another name for
a variation of weak type hints.

If I recall, the previous effort died due to the emotional stress of
getting to the point where the differences between strict type hints and
non-strict type hints was well understood, and everyone's position on those
two points was crystallized. There were still a few proponents of strict
type hints, but it seemed they were willing to live with non-strict type
hints. At that point, everyone became more interested in having a 5.4, and
scalar type hints were left for a time.

On Mon, February 27, 2012 1:15 pm, Kris Craig wrote:
> Now, to rewind a bit past the latest chunk of "I hate this idea"
> posts....
>
> I'd like to suggest a new term: "strong".
>
> This term would be similar to "weak", except with a few key
> differences:
>
> - Weak would behave very much like Arvids suggested in his earlier
> post;
> i.e. if the variable is an integer but you pass a string (like
> "aaa") to
> it, a warning would be thrown and PHP would attempt to convert it
> (i.e. it
> would become 1).

> - Strong, on the other hand, would throw a fatal error if you
> attempted
> to pass an incompatible value to an array. Or, to put it another
> way, if
> the "converted" value does not match the original value. For
> example, if
> we're assigning "aaa" to an integer, that would convert to 1; and,
> since
> "1" != "aaa", a fatal error would be thrown. On the other hand, if
> you
> were to pass the string "1" to that integer variable, it would
> convert to
> 1; and, since "1" == 1, there wouldn't be a problem.

Converting "aaa" to 1 causes the error...

Converting "aaa" to the backwards-compatible means "aaa" == 0 will
return TRUE, and your test for reverse engineering will not help.

This is still a nitpick, as I'm sure you could eventually come up with
some way to validate your strict-ness of conversion.

It would be more cumbersome and slower than using PCRE or ctype_* to
validate or === to guarantee the data types match.

But you can do it.

And I'd love to see an extensive patch in an RFC rather than this
endless back-and-forth.

Neither Stas nor I are saying it shouldn't be done.

We're saying it's been tried and failed, but if you want to be the
little engine that could, the proper place is in an RFC with a
community-drive patch that can be evaluated on technical merit.

> - In both instances, if the converted value matches the original
> (i.e.
> "1" == 1), no warning error would be displayed. Should it perhaps
> display
> a notice though? Or no error at all? I can think of reasonable
> arguments
> on both sides of that question.

I'm pretty sure backwards-compatibility is going to trump, and "no
error at all" will win out.

> This new term would also make it easier for us to avoid using the term
> "strict," which would explode even in the case of "1" == 1.

This is a good idea to distinguish between strict typing throughout,
and judiciously applied strict typing.

I fully support calling it "strong" for clarity purposes.

> Whether this should be done at the function level, the variable level,
> or
> both is an open-ended question.

> weak int $i = "aaa"; // Converts to 1 and throws a warning.

What purpose would 'weak' serve?

If you want the old default behavior, just leave out the 'weak'.

And we already have (int) $i = "aaa" // converts to 0 as ztype int.

Or perhaps I'm missing something where 'weak' is supposed to invert
the current logic of "aaa" -> 0 and you actually want it to be 1 and
not backwards compatible?

I must be missing something here, then, because that just plain
doesn't make sense to me, personally.

> strong int $ii = "aaa"; // Throws a fatal error.

Okay.

E_FATAL seems drastic to me, but I'm not even going to use "strong" so
don't really care either way, I suppose.

I can always set my error handler to over-ride the level of your
error, and even pick out the specifics to change it to whatever I
want...

I respectfully suggest you'll want to discuss the actual level of
error among proponents of the strong typing, and put the consensus in
the RFC.

> weak int $i = "1"; // Converts to 1.

Again, old-school (int) or set_type covers this.

Adding new keywords to fulfill the same purpose seems like bloat to me...

> On Mon, 2012-02-27 at 13:05 -0600, Richard Lynch wrote:
>>
>> I'd have to come up with some OTHER scenario not involving fatal
>> error, such as:
>>
>> strict $db = new DB();
>
> The example is wrong. The new operator will always return an instance of
> the given class (or there will be an exception).
> [...]

This is not true. The new operator can return NULL. In fact, the intl
extension uses this extensively:

$ php -d extension=intl.so -r 'var_dump(new Collator());'

Warning: Collator::__construct() expects exactly 1 parameter, 0 given in
Command line code on line 1
NULL

(in fact, I think it's also leaking the object in this case as it should
call zval_dtor before using RETURN_NULL, something I'll look closer to
when I have the time)

Contrast with:

<?php
class A {
function __construct($a) {}
}
var_dump(new A());

Warning: Missing argument 1 for A::__construct(), called in - on line 5
and defined in - on line 3
object(A)#1 (0) {
}

> On Mon, 2012-02-27 at 13:05 -0600, Richard Lynch wrote:
>>
>> I'd have to come up with some OTHER scenario not involving fatal
>> error, such as:
>>
>> strict $db = new DB();
>
> The example is wrong. The new operator will always return an instance of
> the given class (or there will be an exception). Use
>

This is not true. The new operator can return NULL. The intl extension
uses this extensively:

I'm not sure what the precedent is for creating a separate list fork for a
specific topic. Can one of you who knows the answer to that respond to
Richard's suggestion?

As for an RFC, I completely agree. However, it's still a bit too vague to
create an RFC that would be of any value. We at least have to brainstorm
conceptually where we want to go before an RFC could serve any purpose IMHO..

> > no, it is: "come back after you did your homework, and you can provide
> new
> > arguments to the discussion"
>
>
> To be completely fair, I did homework on this. I went back to 2000 on
> marc.info's archives and read almost all of the 400 posts matching the
> search http://marc.info/?l=php-internals&w=2&r=13&s=strict+typing&q=b
> and a bunch of the posts on
> http://marc.info/?l=php-internals&w=2&r=54&s=type+hinting&q=b
>
>
that's nice.
as I mentioned in my previous (and maybe in some other) mail, I think that
it would be __really__ nice to have those discussions summarized.
sorry for replying your mail later than some others, but I was afraid of
the wall of text. :)

> The vast majority of what I found were quite good arguments for
> including the feature. I found quite a bit of "this was discussed to
> death, do your homework and provide new arguments". What's odd, is
> that one of the earliest on-topic threads that I found (2007:
> http://marc.info/?l=php-internals&m=119514660125258&w=2 ) had this as
> the third reply. The only on-topic discussion that I found prior to
> that was in 2006 (almost exactly 1 year prior:
> http://marc.info/?l=php-internals&m=116257685415135&w=2 ).
>
> Discussed to death. Yet only one time before (discussing a specific
> patch)...
>

I only joined the lists like 3 years ago, but I remember discussing this
idea more than that.
I can dig up the threads if you are interested, the biggest discussion was
after Derick commited the scalar typehint patch from Ilia to trunk and
after a pretty heated and long discussion and multiple alternative
proposals the patch was reverted and Derick implemented a Reflection based
infrastructure for checking the typehints.

with the new RFC process there is a rule of thumb/gentlemen agreement that
if a large portion of the core devs are against a specific change, then it
shouldn't be added, or to form it otherwise consensus should be reached
instead of pushing through changes by 50%+1 (or 66%+1).
this specific change was such a controversial one that we couldn't reach
conclusion..

>
> There were also quite a few problems identified with scalar hinting
> and auto-casting vs strict erroring. However, there were also
> solutions proposed to nearly each and every one of them.
>

There were ideas, but they didn't have enough traction.
IMO we can't have a proper solution without changing the existing behavior
for complex types, if you implement strict typing for scalars that turns
the language strict typed, if you add dynamic/weak typing for the scalars,
you will have an inconsistent implementation.

>
> And the opponents still said no...
>

to tell the truth they said no, but it was the original commiter who
reverted the change.
(sorry Derick, I don't remember the details, feel free to correct me on
this.)

>
> It has been brought up time and time again. Solutions have been
> proposed which have no fundimental issues (inconsistencies,
> problematic operations - such as references, etc)...
>

> And the opponents instead said "this has been discussed to death, no"...
>

nope, they first discussed to death. then when people without much insight
or knowledge without the past discussion brought back the topic, some
people felt that it is too soon to discuss it again, as nothing new is on
the table.

>
> Please can you stop saying "this has been discussed to death". To be
> frank, don't stop the discussion because you don't like the idea. It
> has been discussed to death. But the discussion has only really ever
> involved people who are for it. The opponents by and large have used
> two arguments: "It has been discussed already, so no" and "don't make
> PHP into Java".
>

I don't mind what others do with their free time, so feel free to discuss
it, but somehow it seems for that some people are wasting their time
running the same circles others did years before, and yelling others for
not reading through 50 mails (from which maybe 5-10 has insightful
comments) or wanting to discuss the topic in detail.
I really think that after seeing this as a hot topic as it is, that we
don't have a proper wiki page summarizing and linking all of the previous
discussions. That way even if we can't find the final/best solution, we
could continue the discussion anytime, and we could just point
the newcomers to that page, and they would be able to catch up.
I really think that it is no bad intention from the php devs side in this
topic, but they are burned out discussing this, and the general tone and
finger pointing of this thread doesn't really help the issue.
If somebody have the time, and would like to move this forward, the first
step would be to trying to understand the issue and hand, gathering all
previous discussion/info available, creating a wiki page then:
- document what is the current typehinting implementation, what are the
pro/cons.
- what are the pros/cons for scalar type hints in general.
- what are the pros/cons for weak/strict scalar type hints in general
- what are the previously suggested solutions/implementations, what are the
pros/cons for them
- (optionally do the same for the return type hints)

> There has been some discussion of technical merit and problem
> resolution by opponents, but finding it is VERY difficult among all
> the down trodding commentary.
>

I found your usage of the word opponent a little bit disturbing, but maybe
I'm just thinking into it too much.
I agree that it is frustrating if your arguments are turned down that "we
already discussed that" (been there, done that. I mean in your situation).
I also think that it would also help if the signal/noise(+personal attack)
ration would be better. Usually I try to follow the discussion on the list,
but I have to tell you that I'm almost out of being able to do that, as the
discussion seems to have lack of focus (Scalar type hinting, Object
Casting, both spawned from the ENUM proposal and there are also 3-4 other
hot topics currently.).
I think that we all should calm down a little bit, and catch up with the
reading and focus on how to solve the issue instead of just trying to prove
that the "opponent" is wrong.

>
> So let me make a plea:
>
> If you don't like this feature, and you can explain from a TECHNICAL
> perspective why, please do so! If you don't like the feature, and are
> going to lean on "It's not Java", or "We've discussed this to death
> already", please don't...
>

This goes both way, so one side would need to not turn down the other
simply based on the past discussion, but the other side should also read
those discussions if provided.
I think that I expressed my personal opinion and linked a few articles and
I can also gather some of the discussions on the mailing list (at least
what took place after me joining the list).
Now it would be nice if you could point out that what are your solutions
those technical arguments brought up there.

>
>
>
> And to be fair: "and you can provide new arguments to the discussion"
> has already happened quite a bit (dating back the past 5 years), but
> those arguments were ignored or overruled for political reasons.
>

> +1 what Anthony said.
>
> Guys, seriously. Some of these responses have been downright rude and
> inappropriate for a constructive dialogue. Please do not pollute this
> thread with cliche, "Just find another language and get out!" posts. It
> doesn't add anything to the conversation and instead just creates needless
> anger and animosity. It's immature and just makes it look like we're
> incapable of having a rational discussion.
>
> So, let me outline a list of "arguments" that will carry ZERO weight on
> this thread:
>
> - "If you don't like PHP as it is, goto Java (or some other language)!"
> - "We've already talked about this before. Therefore, we must never
> speak of it again."
> - "This is impossible. Why? Because I said so. You want evidence?
> Fuck you."
> - "But this would require significant changes to the core source
> code! We'd never be able to find enough sacrificial penguins to appease
> the gods!"
> - "Anyone who likes this idea is either stupid or not a 'true' PHP
> developer."
> - "If you disagree with me, it means you haven't done your homework
> because I'm always right."
> - "Strict typing would break everything! What? You're not talking
> about C-like strict typing? Sorry, I didn't catch that. Strict typing
> would break everything!...."
> - "I don't care if you've already countered my argument. I'll just
> keep repeating myself as if you didn't."
>
>
> Variations of the above statements have been posted ad nauseum. They're
> all based on logical fallacies and are not constructive.
>
> I'm putting this out there: If anyone posts one or more of the above
> arguments yet again on this topic, I will personally extract one of your
> kidneys and sell it to a questionable "dog food" company in Shanghai. I
> will then openly mock your intellectual laziness and encourage people to
> ignore you. ;P
>
>
> I'd love to prove Daniel wrong, but I think he may be on to something....
> :\
>
>
it is weird that you are calling others rude.
I'm sure you would feel hurt/personally attacked, if somebody would create
a similar list of the little bit twisted arguments of yours.
could we stay on the topic?
another 14 mails to read. :/

Lol be my guest. You won't have much success though because I have not
relied upon hyperbole and logical fallacies to substantiate my arguments.
On the contrary, my argument thus far can be summarized thusly:

- The issue of type hinting isn't going to go away, otherwise it would
have by now.
- This feature, if implemented correctly, won't "break" PHP or
compromise backwards compatibility.
- I will push back against any efforts to silence this discussion as has
been done in the past.
- If you can't disagree with someone without accusing them of being
ill-informed, disloyal, or just plain dumb; then you're not contributing
anything constructive to this discussion.

>
>
> On Mon, Feb 27, 2012 at 7:53 PM, Kris Craig <[email protected]> wrote:
>
>> +1 what Anthony said.
>>
>> Guys, seriously. Some of these responses have been downright rude and
>> inappropriate for a constructive dialogue. Please do not pollute this
>> thread with cliche, "Just find another language and get out!" posts. It
>> doesn't add anything to the conversation and instead just creates needless
>> anger and animosity. It's immature and just makes it look like we're
>> incapable of having a rational discussion.
>>
>> So, let me outline a list of "arguments" that will carry ZERO weight on
>> this thread:
>>
>> - "If you don't like PHP as it is, goto Java (or some other
>> language)!"
>> - "We've already talked about this before. Therefore, we must never
>> speak of it again."
>> - "This is impossible. Why? Because I said so. You want evidence?
>> Fuck you."
>> - "But this would require significant changes to the core source
>> code! We'd never be able to find enough sacrificial penguins to appease
>> the gods!"
>> - "Anyone who likes this idea is either stupid or not a 'true' PHP
>> developer."
>> - "If you disagree with me, it means you haven't done your homework
>> because I'm always right."
>> - "Strict typing would break everything! What? You're not talking
>> about C-like strict typing? Sorry, I didn't catch that. Strict typing
>> would break everything!...."
>> - "I don't care if you've already countered my argument. I'll just
>> keep repeating myself as if you didn't."
>>
>>
>> Variations of the above statements have been posted ad nauseum. They're
>> all based on logical fallacies and are not constructive.
>>
>> I'm putting this out there: If anyone posts one or more of the above
>> arguments yet again on this topic, I will personally extract one of your
>> kidneys and sell it to a questionable "dog food" company in Shanghai. I
>> will then openly mock your intellectual laziness and encourage people to
>> ignore you. ;P
>>
>>
>> I'd love to prove Daniel wrong, but I think he may be on to
>> something.... :\
>>
>>
> it is weird that you are calling others rude.
> I'm sure you would feel hurt/personally attacked, if somebody would create
> a similar list of the little bit twisted arguments of yours.
> could we stay on the topic?
> another 14 mails to read. :/
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>

>
> This term would be similar to "weak", except with a few key differences:
>
> - Weak would behave very much like Arvids suggested in his earlier
> post; i.e. if the variable is an integer but you pass a string (like "aaa")
> to it, a warning would be thrown and PHP would attempt to convert it (i.e.
> it would become 1).
>
> why would "aaa" turn to 1? it would be 0 by the php type juggling rules.

>
> - Strong, on the other hand, would throw a fatal error if you
> attempted to pass an incompatible value to an array. Or, to put it another
> way, if the "converted" value does not match the original value. For
> example, if we're assigning "aaa" to an integer, that would convert to 1;
> and, since "1" != "aaa", a fatal error would be thrown. On the other hand,
> if you were to pass the string "1" to that integer variable, it would
> convert to 1; and, since "1" == 1, there wouldn't be a problem.
>
> same error here, it seems that it isn't the typo. putting that aside: so
you say that the type checking would behave the same was as does currently
the == and === operator.

>
> - In both instances, if the converted value matches the original (i.e.
> "1" == 1), no warning error would be displayed. Should it perhaps display
> a notice though? Or no error at all? I can think of reasonable arguments
> on both sides of that question.
>
>
I remember seeing that suggestion before, I think that it was proposed more
than once, seehttp://marc.info/?l=php-internals&m=128159992610321&w=3
did you read that thread?