On Mon, Feb 27, 2012 at 6:38 PM, 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 > > 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. some history: 2006 http://derickrethans.nl/typehints-for-scalar-types.html http://php.markmail.org/message/nalhrp5n5p3srj7u#query:+page:1+mid:nalhrp5n5p3srj7u+state:results 2008 https://wiki.php.net/rfc/typehint 2009 http://ilia.ws/archives/205-Type-hinting-for-PHP-5.3.html http://schlitt.info/opensource/blog/0712_scalar_type_hints_in_php.html 2010 http://ilia.ws/archives/217-Scalar-Type-Hints-are-Here!.html http://schlueters.de/blog/archives/139-Scalar-type-hints-in-PHP-trunk.html http://schlueters.de/blog/archives/148-More-on-scalar-type-hints-in-PHP-trunk.html > And the opponents still said no... > 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)... > maybe I missed those, what are you referring to? I see the ones that I linked + the following: https://wiki.php.net/rfc/typechecking https://wiki.php.net/rfc/autoboxing https://wiki.php.net/rfc/boxingandunboxing https://wiki.php.net/rfc/splweaktypehintingwithautoboxing > 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. > I disagree. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
