Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83489 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 58112 invoked from network); 22 Feb 2015 21:58:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Feb 2015 21:58:55 -0000 Authentication-Results: pb1.pair.com smtp.mail=jgmdev@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=jgmdev@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.169 as permitted sender) X-PHP-List-Original-Sender: jgmdev@gmail.com X-Host-Fingerprint: 209.85.217.169 mail-lb0-f169.google.com Received: from [209.85.217.169] ([209.85.217.169:43090] helo=mail-lb0-f169.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CE/A6-18531-F115AE45 for ; Sun, 22 Feb 2015 16:58:55 -0500 Received: by lbiw7 with SMTP id w7so15161109lbi.10 for ; Sun, 22 Feb 2015 13:58:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mxuneu9DJ3GkG1ZjuY52f4Gu1llquDki9NH9pj1jheg=; b=YseoAIwNv1ymZKJbrKA1qQv9a9Pr/o0s7XbaMCeWudKzYy+WdaTlrkWF78dM/LCxLj 1zMn1jB1jwlA9Xlonec29/OGDGVPPJdq4VhZu8s4BSQBApVNFwAFtNAIWSARsVVFXNbv FvwI+lNZ3u12V45KwIKvWl2uQoW/gUOA6+inrw5iXqbEWco2y3DLe+/h07G/w2iruK5e UvXjU7PPISZzv+pe+n9Xna5fHrcHoykG/qrxm7+8w4PatYBoBIgpJbtJnQtFADwgn0PW CtfTy2hMW6PRcBc2J5CMMzV01yZJABJAVyCUAyeNcO2sR5BcpSl9uOSbZfD1u4dmxX0I nqpA== MIME-Version: 1.0 X-Received: by 10.152.197.34 with SMTP id ir2mr4651486lac.36.1424642332294; Sun, 22 Feb 2015 13:58:52 -0800 (PST) Received: by 10.112.62.228 with HTTP; Sun, 22 Feb 2015 13:58:52 -0800 (PST) In-Reply-To: <54EA3E59.3000706@gmail.com> References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com> <8250289916f5128b5bc1a114428d374e@mail.gmail.com> <54E9E6B5.3030905@gmail.com> <54EA3E59.3000706@gmail.com> Date: Sun, 22 Feb 2015 17:58:52 -0400 Message-ID: To: Stanislav Malyshev Cc: Etienne Kneuss , Anthony Ferrara , Zeev Suraski , PHP internals Content-Type: multipart/alternative; boundary=001a11343d1c260250050fb46462 Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC From: jgmdev@gmail.com (=?UTF-8?Q?Jefferson_Gonz=C3=A1lez?=) --001a11343d1c260250050fb46462 Content-Type: text/plain; charset=UTF-8 2015-02-22 16:38 GMT-04:00 Stanislav Malyshev : > Yes, that's not the case, at least nobody ever showed that to be the > case. In general, as JS example (among many others) shows, it is > completely possible to have JIT without strict typing. In particular, > coercive typing provides as much information as strict typing about > variable type after passing the function boundary - the only difference > is what happens _at_ the boundary and how the engine behaves when the > types do not match, but I do not see where big performance difference > would come from - the only possibility for different behavior would be > if your app requires constant type juggling (checks are needed in strict > mode anyway, since variables are not typed) - but in this case in strict > mode you'd have to do manual type conversions, which aren't in any way > faster than engine type conversions. > So the case for JIT being somehow better with strict typing so far > remains a myth without any substantiation. > > Well, strict on a JIT environment may haven't been proved, but it surely has been proved on statically compiled languages like C. Currently, a JIT in the most cases can't compete to the bare performance of a static compiled language, both in resources and CPU, so how is non strict better in that sense? You can argue a lot about nodejs, but as I said on previous message, at runtime it consumes more memory and cpu and this is mostly due to all the type checking it requires. In that sense if the strict proposal could improve that situation it would be a benefit. > No, it can't be (at least it can't be the _entire_ code of this > function), since the user still can pass non-int into this function - > nothing introducing strict typing in functions, as it is proposed now, > prevents it. What strict typing does is to ensure the error in this > case, but to generate the error you still need the checks! > BTW, your weak mode code is wrong too - there's no need to generate > Variants if you typed the variables as int. You know once coercion is > done they are ints. At least in the model that was now proposed. > > I thought those checks could be optional if generated at call time, thats why I gave these 2 examples: calc(1, 5) -> no need for type checking or conversion, do a direct call calc("12", "15") -> calc(strToInt(value1), strToInt(value2)) calc($var1, $var2) -> needs type checking and conversion if required I was thinking on the sense that before calling a function, type checking could take place and conversion if required, but may be thats even more complicated... So what you are saying is that there is no way of determining the type of a variable (only at runtime), as Zeev explained on the previous messages, since variables aren't typed, checks are mandatory either way. > Please provide a substantiation for this opinion. So far what was > provided was not correct. > Static typed languages -> Direct conversion to machine code Dynamic typed languages with JIT -> Intermediate representation -> Checks -> Conversion to machine code with checks. > Please do not strawman. A lot of people here care about performance, and > you have not yet made case that strict typing has any benefit on > performance, so implying that opponents of strict typing somehow don't > care about performance while you champion it does not match the real > situation. > My intention is just that, clear the doubts, I thought and may still think that strict has some advantages, but I'm been proven wrong and many people with all these insightful information might as well. --001a11343d1c260250050fb46462--