Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58290 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 76500 invoked from network); 28 Feb 2012 22:02:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Feb 2012 22:02:46 -0000 Authentication-Results: pb1.pair.com header.from=simpleshot@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=simpleshot@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender) X-PHP-List-Original-Sender: simpleshot@gmail.com X-Host-Fingerprint: 209.85.212.42 mail-vw0-f42.google.com Received: from [209.85.212.42] ([209.85.212.42:54527] helo=mail-vw0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 64/58-36673-50F4D4F4 for ; Tue, 28 Feb 2012 17:02:45 -0500 Received: by vbjk13 with SMTP id k13so2384657vbj.29 for ; Tue, 28 Feb 2012 14:02:42 -0800 (PST) Received-SPF: pass (google.com: domain of simpleshot@gmail.com designates 10.52.94.75 as permitted sender) client-ip=10.52.94.75; Authentication-Results: mr.google.com; spf=pass (google.com: domain of simpleshot@gmail.com designates 10.52.94.75 as permitted sender) smtp.mail=simpleshot@gmail.com; dkim=pass header.i=simpleshot@gmail.com Received: from mr.google.com ([10.52.94.75]) by 10.52.94.75 with SMTP id da11mr15244807vdb.111.1330466562984 (num_hops = 1); Tue, 28 Feb 2012 14:02:42 -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; bh=HKYsREHTBcRnsy7719xA1qPFg21f6NmUEpAbP9Mlb5Q=; b=tP/TW9xNCDHB+8E7ujwaMJOzNgdeCNczYRi0nQjg0S/SWqo5SyCYbYR1kZA8V6LPVZ BhU5JiABaTpn43pJuC7QqOWF3MR5WHt/h1wizVEOM1nOUmMEw6v+M5FK/WRTlh9nlw4Q JYUGNchpGfH+1DkzOpmxJKH1hEWGc6rMPdKAY= MIME-Version: 1.0 Received: by 10.52.94.75 with SMTP id da11mr12587164vdb.111.1330466562844; Tue, 28 Feb 2012 14:02:42 -0800 (PST) Received: by 10.220.49.65 with HTTP; Tue, 28 Feb 2012 14:02:42 -0800 (PST) In-Reply-To: References: <1330357150.2159.30.camel@guybrush> <4F4C1324.2040905@gmail.com> Date: Tue, 28 Feb 2012 17:02:42 -0500 Message-ID: To: John Crenshaw Cc: PHP Development Content-Type: multipart/alternative; boundary=20cf307f312edd28a004ba0d62dc Subject: Re: [PHP-DEV] Scalar type hinting From: simpleshot@gmail.com (Adam Richardson) --20cf307f312edd28a004ba0d62dc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Feb 28, 2012 at 3:58 PM, John Crenshaw wr= ote: > *From:* Adam Richardson [mailto:simpleshot@gmail.com] > > On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw > wrote:**** > > OK everyone, it seems that some people have forgotten or missed the > original agreement that this thread started with. There is a communicatio= n > disconnect ("strict typing" means horribly different things to different > people right now). Please read through and understand the following > terminology before continuing to post on this thread. We've agreed to the > following terms: > > - "Strict Typing" means the super strict old C style typing *with no > implicit conversions*. (If you really think this is what you want, you ar= e > probably mistaken. Look through prior discussions on this topic. This fai= ls > for numerous reasons, including the fact that almost every input to PHP i= s > a string.)**** > > ** ** > > Where is the term "strict typing" coming from? I've not seen this used to > describe any type system (doesn't mean it's not been used, but I'd really > like to see the usage so I can understand the label.)**** > > ** ** > > Adam, When you say you want =93Strict=94 or =93Strong=94 typing, this (ca= se 1) is > what the opponents of stronger typing think you are asking for, which is > why I=92ve defined it this way. There have been a tiny handful of individ= uals > that really are asking for this, but most people don=92t really want this > level of strictness. Also, this level of strictness is fundamentally at > odds with the nature of PHP, and it=92s just never going to happen. The l= evel > of typing in this first case is littered with problems. I won=92t get int= o it > all, but you can read prior discussions in the archives to see it. Look f= or > the passionate arguments made by typing opponents that talk about =93mass= ive > changes=94, =93destroying the language=94, and =93Go use JSP=94. Scattere= d in there > are some occasional explanations of the actual core issues, all of which > refer to this level of typing. (Incidentally, even C++ is not this strict= , > so this really isn=92t what you want, I=92m sure of it. If this is what y= ou > want, then this isn=92t the thread for you, because this is **not** what > will be advocated or discussed here.) > OK, if this is the case, I'd suggest we use the words "Weak" and "Strong", and then speak to whether a proposal seeks to strengthen or weaken the existing type system. That way we utilize the terminology the labels that the existing programming language discourse community uses. Those performing research on the topics will be able to find the terms used. http://en.wikipedia.org/wiki/Type_system http://www.amazon.com/Programming-Language-Pragmatics-Third-Michael/dp/0123= 745144/ > **** > > **** > > - "Weak Typing" means types in the same sense that the PHP documentation > uses types (for example, the docs indicate substr(string, integer), and > substr(12345, "2") =3D=3D "345".) (If you think you want "strict typing",= this > is probably what you mean.)**** > > ** ** > > Doesn't weak typing mean that the language implicitly converts types for > use according to a set of rules? The opposite of this being strong typing= , > which means the language does not perform implicit conversions.**** > > ** ** > > =93Weak=94 here really means weaker than the =93Strong=94 above, but stro= nger than > =93none=94. Right now PHP has no typing whatsoever. =93weak typing=94 WOU= LD be > typing, but it is flexible, optional, and aggressively uses implicit > conversions. For comparison, by these definitions C++ is halfway between > =93weak typing=94 and =93strong typing=94 (by virtue of operator overload= s, > overloaded functions, and cast operators.) > I'm not sure this is the case. PHP is typically categorized as a dynamically typed language, meaning variables don't hold types, BUT, values do: http://en.wikipedia.org/wiki/Type_system#Dynamic_typing Additionally, PHP performs conversions of values implicitly in many instances, so it's typically referred to as weakly typed (as opposed to strongly typed, although, as you point out, there is a continuum.) Hence, the "=3D=3D=3D" operator compares the values without performing the implici= t type conversions PHP performs on values. http://en.wikipedia.org/wiki/Comparison_of_programming_languages#Type_syste= ms > **** > > ** ** > > This =93Weak typing=94 will give you what you want, and it can work. Most > importantly, it is **not** the thing that goes bump in the night for most > strong typing opponents, which means it is probably possible to gather > sufficient support for this. This discussion is focused on developing a > rock solid proposal for =93weak typing=94.**** > > **** > > - "No Scalar Typing" should be used to indicate the current system (where > there is no provision for hinting at scalar types.)**** > > > And, curious about the "No Scalar Typing"?**** > > ** ** > > This is PHP right now. The language has no provision whatsoever for scala= r > types. Function parameters can be hinted as an array or as a specific > class/interface, but otherwise they are assumed to be absolutely anything= . > I know that for people with a lot of experience in a strongly typed > language this sounds like what they would normally call =93Weak Typing=94= , but > it=92s a 3rd level. =93Weak Typing=94 under these definitions is a lot st= ronger > than what you would call =93weak=94, but it=92s much weaker than what str= ong > typing opponents would call =93strong=94. > It still seems that we'd be best served by referring to PHP's current type system as dynamic (as opposed to static) and weak (as opposed to strong) so we use terms the language design community uses. In this respect, PHP is very similar to Javascript. Now, speaking to what programmers can do to declare their intentions in terms of function parameters, I see what you're talking about. Adding the ability to declare intentions for scalar types, too, would work to strengthen the current type system, although I believe it would still be considered a weak type system when judged against the backdrop of the programming language landscape. Given PHP's dynamic, weakly typed characteristics, this is an interesting topic: http://en.wikipedia.org/wiki/Parameter_(computer_programming)#Datatypes > **** > > ** ** > > It=92s going to take some time to get used to the semantics, but if you w= ant > any typing enhancements you=92re going to have to speak the language of t= he > people you want to convince. The communication disconnect here has been > sinking this proposal for a decade. > Agreed :) Sincerely, thanks for your feedback, John. If you take issue with any of my questions/commentary, please correct my knowledge shortfalls. I'm researching language design as a hobby, and working on a parser for my own language. In addition to the communication disconnect, I'd like to make sure that those who want to keep up with this staggering dialogue will benefit from accurate depictions/terms. Thanks, Adam --=20 Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com --20cf307f312edd28a004ba0d62dc--