Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80586 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 68665 invoked from network); 15 Jan 2015 20:16:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Jan 2015 20:16:59 -0000 Authentication-Results: pb1.pair.com header.from=mails@thomasbley.de; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=mails@thomasbley.de; spf=permerror; 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:54726] helo=dd15934.kasserver.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EA/31-61348-93028B45 for ; Thu, 15 Jan 2015 15:16:58 -0500 Received: from dd15934.kasserver.com (dd0803.kasserver.com [85.13.146.34]) by dd15934.kasserver.com (Postfix) with ESMTPSA id 4674326139A for ; Thu, 15 Jan 2015 21:16:54 +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: <8BABA306-12CE-4568-98F3-419A1557F61B@ajf.me> 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> To: internals@lists.php.net Message-ID: <20150115201654.4674326139A@dd15934.kasserver.com> Date: Thu, 15 Jan 2015 21:16:54 +0100 (CET) Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2 From: mails@thomasbley.de ("Thomas Bley") 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 >