Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79351
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.41 as permitted sender)
Message-ID: <547CA967.20607@gmail.com>
Date: Mon, 01 Dec 2014 09:46:15 -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: Andrea Faulds <ajf@ajf.me>, Robert Stoll <php@tutteli.ch>
CC: internals <internals@lists.php.net>, guilhermeblanco@gmail.com
References: <003c01d00d6e$f4fd77c0$def86740$@tutteli.ch> <868FD3D8-4E80-46F4-872A-125D3FD8F40D@ajf.me>
In-Reply-To: <868FD3D8-4E80-46F4-872A-125D3FD8F40D@ajf.me>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> (2) Add lexically-scoped variables, and allow normal global functions
> to be closures. By this I mean we add something like JavaScript’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’d look something like this:
> 
>         <?php
>         let $x = 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
> 

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?

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. 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.
-- 
Stas Malyshev
smalyshev@gmail.com