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 <kris.cr...@gmail.com> 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 <kris.cr...@gmail.com> 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 <ircmax...@gmail.com>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 <tyr...@gmail.com> >>> wrote: >>> > On Mon, Feb 27, 2012 at 5:16 PM, Michael Morris < >>> dmgx.mich...@gmail.com>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 >>> >>> >> >
