> On 1 Dec 2014, at 17:46, Stanislav Malyshev <smalys...@gmail.com> wrote:
>
> 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
>>
> 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’s not a
sensible example of why you’d 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’t 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’t 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’t think we should make it any
easier for them.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
