Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:79364 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71370 invoked from network); 1 Dec 2014 23:22:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Dec 2014 23:22:09 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.44 as permitted sender) X-PHP-List-Original-Sender: smalyshev@gmail.com X-Host-Fingerprint: 209.85.220.44 mail-pa0-f44.google.com Received: from [209.85.220.44] ([209.85.220.44:62782] helo=mail-pa0-f44.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DF/B6-32869-028FC745 for ; Mon, 01 Dec 2014 18:22:08 -0500 Received: by mail-pa0-f44.google.com with SMTP id et14so12186945pad.3 for ; Mon, 01 Dec 2014 15:22:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=q6ozAl5+9Z1/c1k3Nln6GYRdSbOHpL4UNYaXMkaFhWM=; b=tJ2JgArnTV6tkTvfIWXYAjyyJdtB4bNRPvt8yuQcns0L4AKFD5gicrgnWqMARkNC/u QjJ2pep8khPNLoZ9SMU+hZ4R+2FjNfwTeVyKzweAqeNeUlqWs/rQpyHvVQla5P9l6OfA 7PtTEe4qT0WLLLjSuc8NKgfPpT42F1cnmTapMLkMC081DAaGCQrbu/Sk1Rp+okhHldII wZiLpejvIK+iHYEmBDLyO2/jPMqpBPXOxopr+jIun936f7XNf0Xhs83nV901hZZB75XT cT7kgMt7wTcnHbrEq/ObM1ASfN0kpWxBIWV7LQSE/sBB5V8gnMEMM3PtyV+LGItW18nn wBSA== X-Received: by 10.68.135.3 with SMTP id po3mr459951pbb.52.1417476125243; Mon, 01 Dec 2014 15:22:05 -0800 (PST) Received: from stas-air.corp.wikimedia.org (tan4.corp.wikimedia.org. [198.73.209.4]) by mx.google.com with ESMTPSA id ay4sm1035646pbb.29.2014.12.01.15.22.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Dec 2014 15:22:04 -0800 (PST) Message-ID: <547CF81B.6000200@gmail.com> Date: Mon, 01 Dec 2014 15:22:03 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Rowan Collins CC: internals References: <003c01d00d6e$f4fd77c0$def86740$@tutteli.ch> <868FD3D8-4E80-46F4-872A-125D3FD8F40D@ajf.me> <547CA967.20607@gmail.com> <6ADEDB62-987A-45B7-A677-D7C683906BA4@ajf.me> <10AF7FA1-4CC2-4DAD-A504-42939B5C98D4@gmail.com> In-Reply-To: <10AF7FA1-4CC2-4DAD-A504-42939B5C98D4@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes) From: smalyshev@gmail.com (Stanislav Malyshev) Hi! > To get a bit philosophical: Is it really the language's job to make > that decision? Is there a difference between "encouraging", > "allowing", and "enabling"? I think, yes on both. The PHP tradition is to allow doing stuff that may look weird (most languages won't allow you to do $$foo) but still there are practices that we encourage, especially in OO space, and some even that we enforce quite strictly (such as inheritance rules for methods). > Purely static classes are a reality whether this feature is added or > not. They do things namespaces can't (and probably shouldn't), but Of course, you can create class containing of only static members. The question is whether we need a language construct for ensuring that certain class has only static members. I'm not sure this requires a language-level construct. -- Stas Malyshev smalyshev@gmail.com