Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75558 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 15583 invoked from network); 15 Jul 2014 19:43:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Jul 2014 19:43:42 -0000 Authentication-Results: pb1.pair.com header.from=narf@devilix.net; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=narf@devilix.net; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.219.50 as permitted sender) X-PHP-List-Original-Sender: narf@devilix.net X-Host-Fingerprint: 209.85.219.50 mail-oa0-f50.google.com Received: from [209.85.219.50] ([209.85.219.50:35715] helo=mail-oa0-f50.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A7/26-15121-D6485C35 for ; Tue, 15 Jul 2014 15:43:42 -0400 Received: by mail-oa0-f50.google.com with SMTP id g18so6417837oah.37 for ; Tue, 15 Jul 2014 12:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=devilix.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vGkNVcyFwiRaVAdPl7HUhZpbZpP8Mk260g+7mKv5ZHc=; b=HrmSVvUz21PbF/D2bvtkFa2Utryct8wNWpUHvvyf0oFooVVivve7LnfqczypUk/ScT fIJlEPoieGjm0pdTpA2RQi/tS+5kBImsXAgirUqIcwBzYoak6CfAccQcCbn5L8v638Qg hDiu4ut3pUdcVkVPhNdsCtcW5JfJW0ztaw/ug= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vGkNVcyFwiRaVAdPl7HUhZpbZpP8Mk260g+7mKv5ZHc=; b=SPULeHwD+lYIQ3sdJUeq8UJE6wGcAfwSlrmZh029JijWC9hyotydjZ2vTdiPYcVASd mVl2qztFd/ms4TF+3MoaP7zFO+Qoryig4I1YP68HWTPzb8PUfpVcB0CiElbc5EooXVsg E2d6KaFLT6ZHhmsLmkcSM/zPKZw/66GfTysX0kcOcn0EPCO9lY+ZNJxtfUmRmCw5/spl x4wG885gRl/Rz/3kXcPn7TjF62WTGvMgAu5Ts2cpga+Kld4V40YTgzLqu3cpyiFXPxok bnSBrPP8cyD+fZIey4hX0u2rn/+vYLOzS3JH3BrPmI/cbfPRfuwDi0cEmGW1JUV2uGGJ 1pIw== X-Gm-Message-State: ALoCoQlGmkbKupPhW6BvuGYzOJSoUUYww0WYffJqrw2PKLyfxQvf15e6PCgpw8RRlaF+knprnf73 MIME-Version: 1.0 X-Received: by 10.182.255.201 with SMTP id as9mr7942522obd.44.1405453418873; Tue, 15 Jul 2014 12:43:38 -0700 (PDT) Received: by 10.202.75.205 with HTTP; Tue, 15 Jul 2014 12:43:38 -0700 (PDT) In-Reply-To: <53C563B3.6060905@gmail.com> References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me> <05CE2216-C5D9-4937-9F2E-AA1407284D9F@ajf.me> <53C460DF.5040304@sugarcrm.com> <53C53A96.2040303@gmail.com> <53C55342.1010207@sugarcrm.com> <53C563B3.6060905@gmail.com> Date: Tue, 15 Jul 2014 22:43:38 +0300 Message-ID: To: Rowan Collins Cc: Stas Malyshev , "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening) From: narf@devilix.net (Andrey Andreev) On Tue, Jul 15, 2014 at 8:24 PM, Rowan Collins wrote: > The logical conclusion from that is not to have type hints at all. So far, > that is in fact the only consensus the PHP community has ever reached - not > to have scalar type hints. I'm sorry, I know what you mean here and I'm not criticizing you specifically (in fact, I'm intentionally taking it ouf of context), but that's "PHP internals", not "PHP community". The PHP community that I know, wants to have _both_ type cast hinting and strict type declarations. PHP internals on the other hand, would rather argue to death over which specific version of the two is the one and true way to rule them all. We had that with the ArrayOf hints too, which turned into ArrayOf vs Generics. Heritage this, history that, consistent with X, inconsistent with Y, don't forget the special case Z, "use another language", "that's been proposed already" ... That is why an Nth iteration of scalar type hinting is being discussed, not because it's so damn hard to do it right. Doing it right here means to understand that everybody wants scalar type hinting for different use cases and to try to satisfy use case A without excluding use case B as a possibility in the future. Sorry about the rather aggressive remark, but somebody had to say it. Cheers, Andrey.