> 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
