Err typo correction: "Strong, on the other hand, would throw a fatal error
if you attempted to pass an incompatible value to *a variable." (not "an
array")
--Kris
On Mon, Feb 27, 2012 at 11:15 AM, Kris Craig <[email protected]> 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.
> - 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
>>>
>>>
>>
>