Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80592 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78629 invoked from network); 15 Jan 2015 20:59:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Jan 2015 20:59:08 -0000 Authentication-Results: pb1.pair.com smtp.mail=mails@thomasbley.de; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=mails@thomasbley.de; sender-id=unknown Received-SPF: error (pb1.pair.com: domain thomasbley.de from 85.13.137.24 cause and error) X-PHP-List-Original-Sender: mails@thomasbley.de X-Host-Fingerprint: 85.13.137.24 dd15934.kasserver.com Received: from [85.13.137.24] ([85.13.137.24:55798] helo=dd15934.kasserver.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9F/43-61348-A1A28B45 for ; Thu, 15 Jan 2015 15:59:08 -0500 Received: from dd15934.kasserver.com (dd0803.kasserver.com [85.13.146.34]) by dd15934.kasserver.com (Postfix) with ESMTPSA id 802BC26139A for ; Thu, 15 Jan 2015 21:59:02 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SenderIP: 178.19.222.74 User-Agent: ALL-INKL Webmail 2.11 In-Reply-To: <20150115201654.4674326139A@dd15934.kasserver.com> References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me> <4E2073DE-0951-498C-97BB-DDAC094F11FA@ajf.me> <9a033dd1f223f854e760924d118ab812@mail.gmail.com> <2ae0164cb9b9bf1c974d7a3c60af0466@mail.gmail.com> <6105ea99002e634373c09685310e26a6@mail.gmail.com> <8BABA306-12CE-4568-98F3-419A1557F61B@ajf.me><20150115201654.4674326139A@dd15934.kasserver.com> To: internals@lists.php.net Message-ID: <20150115205902.802BC26139A@dd15934.kasserver.com> Date: Thu, 15 Jan 2015 21:59:02 +0100 (CET) Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2 From: mails@thomasbley.de ("Thomas Bley") For me personally, I would use strict hints for private/protected methods and weak hints for public methods. Regards Thomas Thomas Bley wrote on 15.01.2015 21:16: > What about doing both weak and strict with two different syntaxes? > > public function __construct(string $name, $age as int, $cuteness as float, bool > $evil) { > > string $name // strict > $age as int // weak > $cuteness as float // weak > bool $evil // strict > > "as" Syntax is taken from SQL92. > > Regards > Thomas > > > Andrea Faulds wrote on 15.01.2015 20:52: > >> Hi Andrey, >> >>> On 15 Jan 2015, at 19:20, Andrey Andreev wrote: >>> >>> Consider this badly designed API: >>> >>> declare(strict_typehints=TRUE); >>> >>> const MODE_APPEND = 0; >>> const MODE_TRUNCATE = 1; >>> const MODE_PREPEND = 2; >>> >>> function write_file(string $path, int $mode, string $data) >>> { >>> // it's quite obvious >>> } >>> >>> Somewhere else, you forget the parameters order ... >>> >>> declare(strict_typehints=FALSE); >>> >>> $path = '/important/file.dat'; >>> $data = '1 year'; >>> $mode = MODE_APPEND; >>> >>> write_file($path, $data, $mode); >>> >>> It's a bad example - an awful (and indeed, very much useless) API, >>> combined with an absent-minded consumer. Yet, it demonstrates how >>> putting the caller in control *can* cause a disaster. >> >> Sure, weak typing is much poorer than strict typing for error checking. Does >> that mean the user should be prevented from having the choice? >> >> Are you simply opposed to the idea of weak types in general? >> >>> What I would suggest is the '(type) $weak' vs 'type $strict' syntax >>> that was already mentioned. >>> >>> I've said this before, during the previous RFCs discussions - all of >>> these proposals will fail, because they all suggest using the 'type >>> $whatever' syntax and that automatically upsets the "other camp", >>> whichever it is, but especially if the "other camp" is supporters of >>> strict typing. That's the moment when they become opposition, while >>> they could've otherwise not care because it's simply not their >>> "battle". If both are proposed to co-exist in a clean way (instead of >>> via a switch), I believe that we'll get substantially more positive >>> opinions from both sides. >> >> Both co-existing doesn’t solve anything, if anything it makes it worse. >> >> People who like weak typing don’t want to have to use APIs with strict type >> hints. If you’re like Zeev and believe it is fundamentally at odds with PHP, >> you’ll especially dislike it. >> >> People who like strict typing don’t want to have to use APIs with weak type >> hints. >> >>> >>> And to hell with the "consistency" argument. Since when did PHP become >>> *that* concerned about purity and high consistency levels? >> >> I don’t care if PHP is concerned about it. I am concerned about the mess >> caused by having two or three different argument type checking modes being >> used >> within the same function. >> >> Marco and S.A.N.: >> >>> >>> On 15 Jan 2015, at 19:45, Marcio Almada wrote: >>> >>> Hi, >>> >>> I would like to call everyone's attention, specially people >>> contributing directly to this RFC series, to what S.A.N just said: >>> >>> > Many developers PHP offers dual syntax: >>> > >>> > 1. Strict >>> > function bar(int $num){} >>> > >>> > 2. Lax >>> > function bar((int) $num){} >>> > >>> > Maybe it makes sense to put this option on the ballot if it passes a vote, >>> > it will be possible to put an end to the discus? >>> >>> >>> This idea has been **so recurrent** and yet systematically ignored by RFC >>> owners. Why? I think that we need to baby step and try to approve coercive >>> type declarations first and decide upon a possible stricter type check later: >>> >>> How a bout a reboot of what ircmaxell@php.net already started in >>> https://wiki.php.net/rfc/parameter_type_casting_hints for v0.3? >>> >>> PS: Please, let's not fall into the mindset of "if v0.2 is not a good idea >>> then v0.1 instantly becomes more acceptable", we still have time to try some >>> alternatives. >> >> See what I said above to Andreey. >> >> This RFC doesn’t ignore having two syntaxes. It sets out to avoid the >> nightmare that two syntaxes would cause. >> >> Thanks. >> >> -- >> Andrea Faulds >> http://ajf.me/ >> >> >> >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >