Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:79356 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 53231 invoked from network); 1 Dec 2014 20:30:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Dec 2014 20:30:55 -0000 Authentication-Results: pb1.pair.com smtp.mail=ajf@ajf.me; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ajf@ajf.me; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.245 as permitted sender) X-PHP-List-Original-Sender: ajf@ajf.me X-Host-Fingerprint: 198.187.29.245 imap11-3.ox.privateemail.com Received: from [198.187.29.245] ([198.187.29.245:35097] helo=imap11-3.ox.privateemail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A9/B3-32869-CFFCC745 for ; Mon, 01 Dec 2014 15:30:54 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.privateemail.com (Postfix) with ESMTP id B8A328800DB; Mon, 1 Dec 2014 15:30:49 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at imap11.ox.privateemail.com Received: from mail.privateemail.com ([127.0.0.1]) by localhost (imap11.ox.privateemail.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VikmnhskdpfY; Mon, 1 Dec 2014 15:30:49 -0500 (EST) Received: from oa-res-27-210.wireless.abdn.ac.uk (oa-res-27-210.wireless.abdn.ac.uk [137.50.27.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.privateemail.com (Postfix) with ESMTPSA id 638BF8800DA; Mon, 1 Dec 2014 15:30:48 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) In-Reply-To: <547CA967.20607@gmail.com> Date: Mon, 1 Dec 2014 20:30:46 +0000 Cc: Robert Stoll , internals , guilhermeblanco@gmail.com Content-Transfer-Encoding: quoted-printable Message-ID: <6ADEDB62-987A-45B7-A677-D7C683906BA4@ajf.me> References: <003c01d00d6e$f4fd77c0$def86740$@tutteli.ch> <868FD3D8-4E80-46F4-872A-125D3FD8F40D@ajf.me> <547CA967.20607@gmail.com> To: Stanislav Malyshev X-Mailer: Apple Mail (2.1993) Subject: Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes) From: ajf@ajf.me (Andrea Faulds) > On 1 Dec 2014, at 17:46, Stanislav Malyshev = wrote: >=20 > Hi! >=20 >> (2) Add lexically-scoped variables, and allow normal global functions >> to be closures. By this I mean we add something like JavaScript=E2=80=99= s >> `let` keyword that would make a variable that is unset when it falls >> out of scope (end of a {} block, end of a file etc.). Then, we allow >> normal functions to use the `use ($var)` syntax and close over >> variables. That=E2=80=99d look something like this: >>=20 >> > let $x =3D 0; >> function getCounter() use(&$x) { >> return $x; >> } >> function incrementCounter() use(&$x) { >> return $x++; >> } >> // since this is the end of the file, $x falls out of scope >>=20 > Moreover, since your example is clearly not a singleton - it is hard = to > imagine any program that would have use for just one counter but never > any more - it is a classic example of something that should be an > object. That was just a frivolous example to show how the syntax works, it=E2=80=99= s not a sensible example of why you=E2=80=99d want this functionality. > This looks like you're trying to create a class without calling it a > class. Now, I agree that not everything should be a class. But what > you're doing - set of functions linked by common behavior and sharing = a > common state - is a perfect fit for something classes and objects are > used in PHP. So why not just use them instead of inventing creative = ways > of doing the same but in more complicated way? > It might be a wrong example, but I have hard time seeing any > example of something that has a group of functions, bound by common > functionality, has a shared state and still should not and can not be > expressed as a class/object. That's literally what they are made for. > Now, utility classes do suck, but they suck not because they do what = you > described - on the contrary, they suck exactly because they are = usually > a bag of random, unrelated functions bound by nothing but the common > trait of "we don't have other places to put them in". But for that, > plain old functions work just fine in PHP. Yeah, I see your point. For encapsulated state with associated functions = to work with that state, a class is the way to go. For miscellaneous = functions with no shared state, they should just be functions, not in a = class. However, I still don=E2=80=99t think `static` is a good idea. Adding = function autoloading eliminates one use case - a bag of random, = unrelated functions. But it leaves the other: a set of functions to = operate on global state. The problem is that, well, global state is = rarely a good thing, I don=E2=80=99t think we should be encouraging it. = If people really want to make a singleton or a final class with a = private constructor, be my guest, but I don=E2=80=99t think we should = make it any easier for them. -- Andrea Faulds http://ajf.me/