Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71334 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 6616 invoked from network); 20 Jan 2014 19:17:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Jan 2014 19:17:52 -0000 Authentication-Results: pb1.pair.com smtp.mail=php@golemon.com; spf=softfail; sender-id=softfail Authentication-Results: pb1.pair.com header.from=php@golemon.com; sender-id=softfail Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.192.178 as permitted sender) X-PHP-List-Original-Sender: php@golemon.com X-Host-Fingerprint: 209.85.192.178 mail-pd0-f178.google.com Received: from [209.85.192.178] ([209.85.192.178:38981] helo=mail-pd0-f178.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AE/14-02192-E567DD25 for ; Mon, 20 Jan 2014 14:17:51 -0500 Received: by mail-pd0-f178.google.com with SMTP id y13so7197606pdi.37 for ; Mon, 20 Jan 2014 11:17:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AIpIPVnK5VIEptZnTrGmVEnidRtuCdVU0aoNjKVYWkk=; b=BCGsyUuyEphcXziphnL6Kn+AKG+/hLIaH7e6My3uYUFAt0RDKToNt+xPZ4yM7STvzo nD2/0ilA7XKOKpgqJYO/hB7pel/OdRlNpXyPo+uUV2UPizK4YSLep1aK0b0H96eQIuvy wTcgHD96jTcDgYl5+a9R1MbLloUcpP04KBkx9ylEwWZUhCtNh9xYHV8cOdxlmRWK5xGO neIJ6kBESXson2GU+Azi23fROLjPBAph80ut1AqlP3HvwSi/+Jgq0a0dIBBpRk8E94Eg HjvKD/s+3MxpB2MpfTzMU9li6n5zi9tm6JV/wIAEyTbVXsoh/NeIaa3lD5TvLL/xkKI8 GiAg== X-Gm-Message-State: ALoCoQlSPN2QMKVVRAy8sqo7Pw65siNkm+1m2mV2uFkRAB1im2V85UiTyaRKCgetSA04Sfkc2pEV MIME-Version: 1.0 X-Received: by 10.68.196.226 with SMTP id ip2mr19191557pbc.106.1390245468383; Mon, 20 Jan 2014 11:17:48 -0800 (PST) Sender: php@golemon.com Received: by 10.70.77.164 with HTTP; Mon, 20 Jan 2014 11:17:48 -0800 (PST) X-Originating-IP: [2001:470:1f09:2fa:22c9:d0ff:fe87:295b] In-Reply-To: References: <002d01cf1234$01e6dc60$05b49520$@tutteli.ch> <004c01cf123d$35730870$a0591950$@tutteli.ch> <52D71748.1090402@googlemail.com> <52D71FAE.8030002@ajf.me> <005001cf124f$3a40df00$aec29d00$@tutteli.ch> <20140116110127.202079vzjsj76n7b@webmail.tutteli.ch> <0B.B1.24763.139B7D25@pb1.pair.com> <002001cf12da$2bfbda90$83f38fb0$@tutteli.ch> <52DCA3E7.80602@lerdorf.com> <52DCED71.3020207@pthreads.org> <006301cf15f5$22f8df60$68ea9e20$@tutteli.ch> Date: Mon, 20 Jan 2014 11:17:48 -0800 X-Google-Sender-Auth: 9TsMrtjsg1cXqRRVo1Qn7RyAMt0 Message-ID: To: Philip Sturgeon Cc: Robert Stoll , Joe Watkins , "internals@lists.php.net" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] Introducing "Array Of" RFC From: pollita@php.net (Sara Golemon) > Short version: "This RFC is not about Scalar Type Hints or Generics" > But it is. "ArrayOf", whatever form it takes, is incomplete without scalar specializations. Is implementing half-a-feature (arrayof without scalars) good enough? Maybe, but that doesn't mean we shouldn't be having that discussion. > There have been a lot of people suggesting various types of syntax. As > Joe said, using generics syntax for not generics would be a travesty, > and an overcomplication of what should be a simple feature. > ArrayOf is not a separate topic from Generics, it is by definition a narrowly-scoped form of generics. "ArrayOf Foo" is a "Foo" specialization of the array generic (even if it's not labeled as such due to not having other types of generics). "This is an array, but it's an array just for Foos". Can arrayof be implemented in a way which hides this heritage? Sure, but should it? > I'd really like it if we could discuss just this feature, and keep the > generics, OOP arguments, anti-type-checking, and "bemoaning of > edge-case performance issues on type system that needs some love > anyway" conversations for other threads. > Just reinforce my points above, I disagree with this paragraph. Looking at specific cases while ignoring the larger picture of the language's design is what gets us into ugly corners (inconsistently named functions, parameter ordering, multiple autoloader mechanisms, etc...) Ignoring elements which fit closely together is a short-sighted mistake. -Sara