Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82534 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 82740 invoked from network); 12 Feb 2015 13:48:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Feb 2015 13:48:05 -0000 Authentication-Results: pb1.pair.com smtp.mail=pajousek@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=pajousek@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.46 as permitted sender) X-PHP-List-Original-Sender: pajousek@gmail.com X-Host-Fingerprint: 209.85.192.46 mail-qg0-f46.google.com Received: from [209.85.192.46] ([209.85.192.46:60565] helo=mail-qg0-f46.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C0/06-50473-31FACD45 for ; Thu, 12 Feb 2015 08:48:05 -0500 Received: by mail-qg0-f46.google.com with SMTP id z107so7872522qgd.5 for ; Thu, 12 Feb 2015 05:48:01 -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:content-transfer-encoding; bh=U+Qvb0gejm6LN7wB5eakrHZGnXFwWTLYAJ211D1jWA4=; b=eikGi1xb4CqwscXGLUBOMNcCht27oc7pF9W7T7+6Fy9L8NxYx3PReOc0TOqYftKiLp WE27w6yLXt2EgiPXUq6Q/ZEa5UF4aZhQjps1qKB4P0DOWWX8s1msGrYQ3oOsyVU22xGr okLCz6hqGb5y3vIDzuOdxd9Gx2vys0iF31vnj6I7nZEd6PpD253IA3raI2HMSEQxeu9c rj2ZNbpSrlC3KrHyWHJqAPou5pDhBjPcK7+U1gM+2DpjIhRGT2Axo6X3Muo/dDeofsMN o62XiXSWQtJOzKcHY8mmDS4+1vHxTOL0R9w653/ZN2s/4tVKjnvUeQY0nZbronOQTjvG TryA== MIME-Version: 1.0 X-Received: by 10.140.232.206 with SMTP id d197mr36688qhc.79.1423748881274; Thu, 12 Feb 2015 05:48:01 -0800 (PST) Received: by 10.96.66.201 with HTTP; Thu, 12 Feb 2015 05:48:01 -0800 (PST) In-Reply-To: <85D76C91-9A9E-459B-847A-619AA21B9262@ajf.me> References: <8703B53E-2C4A-4AC6-95C4-D4F19C6D5221@ajf.me> <54DAF884.7000508@lerdorf.com> <203e611c8e0b03568a868b8d931aec37@mail.gmail.com> <61E01A7C-C5C8-447F-A8FA-E12A18E847CA@ajf.me> <85D76C91-9A9E-459B-847A-619AA21B9262@ajf.me> Date: Thu, 12 Feb 2015 14:48:01 +0100 Message-ID: To: Andrea Faulds Cc: "guilhermeblanco@gmail.com" , Zeev Suraski , Rasmus Lerdorf , PHP Internals Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints From: pajousek@gmail.com (=?UTF-8?Q?Pavel_Kou=C5=99il?=) On Thu, Feb 12, 2015 at 1:45 PM, Andrea Faulds wrote: > Hi Pavel, > > C# also doesn=E2=80=99t have dynamic typing. Plus, adding overloading to = an existing language is more difficult. > C# does have dynamic typing. Adding method overloading to an existing language may be more difficult than creating a new language from ground up, but I'd guess it's definitely not impossible (I can't say for sure, because I do not know C and PHP's internals). >> Overloading on scalar types - unpredictable how? Even with weak calls, >> the best candidate could be chosen? > > Still likely to cause chaos. If you can overload based on scalar types, t= hen foobar($a / 2) could call any of *three* different functions. > Sorry, but if you create functions foobar(int $x) and foobar(float $y) which do totally different things, I'd argue that you brought the chaos upon yourself. About the third option for called function, I'll have to admit that I do not know of any other possible signature of a function that the call could lead to, if we go by "choose the best candidate" strategy for resolving. >> Of course, sometimes there will be >> an abmbiguous call, but as long as there would be a way to define >> which call you want, it shouldn't be a problem as well? > > =E2=80=9CA way to define which call you want=E2=80=9D? Sounds like a hack= y workaround to me. > Scratch that, I was thinking about something else while writing this. Error on an ambiguous call is probably the best way to handle this. >> Poor API - for useland code or in PHP's functions itself? But I don't >> think this should be considered as a real problem, because in userland >> code, developers are able to create a poor API even with the current >> versions of PHP. > > That doesn=E2=80=99t mean we should make it any easier. > I just don't believe that method overloading would suddenly make everyone write poor programs. Also, they can do the same poor coding with tons of ifs and elses in one method without typehint and declaring multiple types in phpDoc (createFrom($a) and @param X|Y|Z in phpDoc), or they have to create multiple methods which have some suffix (createFromX, createFromY, createFromZ). >> If someone wants to shoot himself in the foot, he >> will do it in one way or another. And at the same time, polymorphism >> via method overloading can lead to a cleaner APIs, if it's used well. > > I don=E2=80=99t see how. The main things it enables are optional paramete= rs (which we already support) and polymorphism (which we already support). = So you=E2=80=99d have to explain what overloading brings to the table beyon= d those two things. > It brings cleaner declarations of methods and functions. Also, it brings the possibility of having operator overloading in user classes someday in the future (yes, this can be abused as well, but it also has legitimate use cases - like class for representing Money and being able to do +, - , / or * operations on them). Is the option of omiting type hints and having optional parameters really a good enough replacement for method overloading polymorphism for you? Because for me, it unfortunately is not. :( >> Well, about "number" type hint. How this would work, in combination >> with strict types? >> >> function bar(float $f) { >> return $f * 1.23; >> } >> >> function foo(number $x) { >> return bar($x); >> } >> >> foo(1); >> >> From my understanding, it wouldn=E2=80=99t? > > It would accept an integer or a float, because both subclass number: > > function foobar(): number { > return 1.0; // okay > return 1; // okay > } > > function foo(number $x) {} > foo(1.0); // okay > foo(1); // okay > > I don=E2=80=99t see why it =E2=80=9Cwouldn=E2=80=99t work=E2=80=9D. Read the example once more, please - the issue I see with it is that bar() requires float, but foo() just number and doesn't convert it to the required type. The most unpredictable thing is that it will work half of the time and half of the time it will just throw errors. Sure, the blame in this case is on all 3 "participants" - strict typing (and no int -> float conversion), programmer itself and "number" typehint (it just doesn't work well with the strict typing) - but as you said, should you make writing poor programs easier? Just kidding with the last sentence :) ... but honestly, I do find method overloading and implicit conversions from int to float a better way to solve the usecases for "number" typehint. Regards Pavel Kouril