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 >> >> >
