Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58201 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71994 invoked from network); 27 Feb 2012 21:52:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Feb 2012 21:52:26 -0000 Authentication-Results: pb1.pair.com header.from=ircmaxell@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ircmaxell@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 as permitted sender) X-PHP-List-Original-Sender: ircmaxell@gmail.com X-Host-Fingerprint: 209.85.216.42 mail-qw0-f42.google.com Received: from [209.85.216.42] ([209.85.216.42:58507] helo=mail-qw0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 06/19-29394-81BFB4F4 for ; Mon, 27 Feb 2012 16:52:25 -0500 Received: by qaui11 with SMTP id i11so1303984qau.8 for ; Mon, 27 Feb 2012 13:52:21 -0800 (PST) Received-SPF: pass (google.com: domain of ircmaxell@gmail.com designates 10.229.76.9 as permitted sender) client-ip=10.229.76.9; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ircmaxell@gmail.com designates 10.229.76.9 as permitted sender) smtp.mail=ircmaxell@gmail.com; dkim=pass header.i=ircmaxell@gmail.com Received: from mr.google.com ([10.229.76.9]) by 10.229.76.9 with SMTP id a9mr7463077qck.76.1330379541909 (num_hops = 1); Mon, 27 Feb 2012 13:52:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TCi4QS+K50AU/6knnLOhuScSJAT6MFS/ujzTPYGnfmA=; b=ew4pGOzl/EfUOqMRzrQ2LrgBgbem9s9BbDbhG1/wC7fAHNx55AvS9iM7wmr7t8L4NQ a1rYHE7SdhYIsEyAn1z6qgwGvPxXCfokaPGELxdXjE6F/YGmJSqL9WoJSjmrO7ovykeK ugdUobaewvti9FzVl4GcWF37TKGS82UndtkY4= MIME-Version: 1.0 Received: by 10.229.76.9 with SMTP id a9mr6122716qck.76.1330379541706; Mon, 27 Feb 2012 13:52:21 -0800 (PST) Received: by 10.229.166.202 with HTTP; Mon, 27 Feb 2012 13:52:21 -0800 (PST) In-Reply-To: References: <1330357150.2159.30.camel@guybrush> Date: Mon, 27 Feb 2012 16:52:21 -0500 Message-ID: To: Ferenc Kovacs Cc: Michael Morris , "internals@lists.php.net" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Scalar type hinting From: ircmaxell@gmail.com (Anthony Ferrara) Ferenc, Thanks for the comments! On Mon, Feb 27, 2012 at 4:09 PM, Ferenc Kovacs wrote: > > > On Mon, Feb 27, 2012 at 6:38 PM, Anthony Ferrara > 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. =A0I went back to 2000 on >> marc.info's archives and read almost all of the 400 posts matching the >> search http://marc.info/?l=3Dphp-internals&w=3D2&r=3D13&s=3Dstrict+typin= g&q=3Db >> and a bunch of the posts on >> http://marc.info/?l=3Dphp-internals&w=3D2&r=3D54&s=3Dtype+hinting&q=3Db >> > > that's nice. > as I mentioned in my previous (and maybe in some other) mail, I think tha= t > 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. :) Without committing to anything, I will try to find time to do so... >> The vast majority of what I found were quite good arguments for >> including the feature. =A0I found quite a bit of "this was discussed to >> death, do your homework and provide new arguments". =A0What's odd, is >> that one of the earliest on-topic threads that I found (2007: >> http://marc.info/?l=3Dphp-internals&m=3D119514660125258&w=3D2 ) had this= as >> the third reply. =A0The only on-topic discussion that I found prior to >> that was in 2006 (almost exactly 1 year prior: >> http://marc.info/?l=3Dphp-internals&m=3D116257685415135&w=3D2 ). >> >> Discussed to death. =A0Yet 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 wa= s > after Derick commited the scalar typehint patch from Ilia to trunk and af= ter > a pretty heated and long discussion and multiple alternative proposals th= e > patch was reverted and Derick implemented a Reflection based infrastructu= re > for checking the typehints. Well, that's absolutely relevant, but that was for one of the possibilities on how to implement it. But worth bringing up... > some history: > 2006 > http://derickrethans.nl/typehints-for-scalar-types.html > http://php.markmail.org/message/nalhrp5n5p3srj7u#query:+page:1+mid:nalhrp= 5n5p3srj7u+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.htm= l > http://schlueters.de/blog/archives/148-More-on-scalar-type-hints-in-PHP-t= runk.html That's quite helpful. >> >> And the opponents still said no... > > > with the new RFC process there is a rule of thumb/gentlemen=A0agreement t= hat > if a large portion of the core devs are against a specific change, then i= t > 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.. I have no problem with the maintainers/core devs saying no if they really feel it's bad (in fact, I agree with it). What I do have a problem with is them (or anyone) saying no without understanding what they are saying no to (which is obvious by some of the comments, and by some of the banter about "PHP is not java"). >> >> There were also quite a few problems identified with scalar hinting >> and auto-casting vs strict erroring. =A0However, 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 behavio= r > 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, yo= u > will have an inconsistent implementation. What behavior would need to be changed for complex types? Adding the ability to hint/cast between trees? I'm kind of confused by this bit... >> 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.) Sure, but again, that's talking about implementing very strict typing (fatal on incorrect). Which to be perfectly honest, I would say no to as well. But I think there's enough merit to continue the discussion, and separate the concepts... But very fair point... >> >> >> It has been brought up time and time again. =A0Solutions 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 I'm talking about in the lists, message by message. Perhaps most of them didn't actually get into RFC, or were glossed over, or lost in the noise... >> >> And the opponents instead said "this has been discussed to death, no"... > > > nope, they first discussed to death. then when people without much insigh= t > or knowledge without the past discussion brought back the topic, some peo= ple > felt that it is too soon to discuss it again, as nothing new is on the > table. I understand that sentiment. I really do. But at the same token, why do we need to kill the conversations from happening? Why not ignore it if you think it's too soon, and let the others get to the point of an RFC with patch, and then step in and see how the idea matured. I think that's my biggest problem with the dynamics of this list. Ideas aren't really nurtured as well as they could be. If the idea is solid, and has an implementation, then it's great. But there are plenty of seedling ideas that get lost or down trodden-ed simply because it's not bulletproof... >> Please can you stop saying "this has been discussed to death". =A0To be >> frank, don't stop the discussion because you don't like the idea. =A0It >> has been discussed to death. =A0But the discussion has only really ever >> involved people who are for it. =A0The 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 runn= ing > the same circles others did years before, and yelling others for not read= ing > through 50 mails (from which maybe 5-10 has insightful comments) or wanti= ng > to discuss the topic in detail. > I really think that after seeing this as a hot topic as it is, that we do= n'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=A0newcomers=A0to 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 t= he > pros/cons for them > - (optionally do the same for the return type hints) I think that was the point of this very thread, if I'm not mistaken... >> >> 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 mayb= e > I'm just thinking into it too much. Well, I mean it as it comes off, to an extent. I mean the very small group of people who are littered in these threads who are saying "PHP is not Java" and shooting down the idea without even considering it (in the least). If you don't think it can be done, that's a different story. I'm talking about the people who have nothing constructive at all to add, yet generate these long diatribes of dialog, without getting anything done... > 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 lis= t, > but I have to tell you that I'm almost out of being able to do that, as t= he > discussion seems to have lack of focus (Scalar type hinting, Object Casti= ng, > both spawned from the ENUM proposal and there are also 3-4 other hot topi= cs > 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 pro= ve > that the "opponent" is wrong. Sounds good to me! >> >> >> 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! =A0If 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 sim= ply > based on the past discussion, but the other side should also read those > discussions if provided. I think that's the problem. I don't mind "It has been discussed before, here and here, can you solve those problems". If links are provided, I think it's 100% reasonable to have people read the links that were provided. I don't consider it reasonable to ask people to "go read prior discussions" without any insight onto which (and which are even valid anymore due to engine changes, and the like). That's like telling someone to just go google it. Sure, but if you don't know what you're looking for, a huge time waster (and a bit disrespectful as well)... > I think that I expressed my personal opinion and linked a few articles an= d I > can also gather some of the discussions on the mailing list (at least wha= t > 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. I'll go through them tonight when I get some free time. Thanks a bunch, Anthony >> >> >> >> >> 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=E1cs > @Tyr43l - http://tyrael.hu