On 4 August 2014 15:02, Andrea Faulds <a...@ajf.me> wrote:
>
> On 4 Aug 2014, at 13:27, Marco Pivetta <ocram...@gmail.com> wrote:
>
> > The fact that I'm arguing about is "yet another method to maintain" for
> an API that can simply live in userland (and is easier to
> maintain/upgrade/etc)...
> > Unless there's a huge overhead, I don't see a problem with creating new
> closures: I do a lot of performance-sensitive stuff with `Closure::bind()`
> and I don't see how this API could help me.
>
> Well, perhaps this API is not aimed at you specifically. The broader
> question is why *shouldn’t* we allow binding $this at runtime like we do
> for any other parameter? Creating a closure only to immediately throw it
> away is a waste of code and time. Since we can permit this, it is useful,
> and it doesn’t cause any problems, I don’t see why we shouldn't.
>
It is a waste of memory, but I'd first like to see an actual real-world
use-case for it. There are simpler ways to avoid the memory usage, by
allowing stuff like following:
$something = function () use (& $object) {};
Then binding the closure to a specific scope and forgetting about `$this`.
That is efficient both memory and cpu-wise.
If it’s really such a maintainability problem (I wouldn’t say so, the
> function’s quite simple), then you can get me to maintain it. After all, I
> wrote it.
>
Yes, but upgrading PHP is a mess (from a
business/bureaucracy/devops/whoeverhatesmeatwork perspective. You can ask
that to some other users of this mailing list that solely use the ml to
vent about that.
Upgrading libraries is easy.
> FooBar::methodName::function vs FooBar::function - clear and simple IMO.
>
> It might be clear and simple, but I don’t think it’s realistic.
PHP 5.5 introduced the `::class` construct, which I currently use quite a
lot and makes refactoring a breeze. I don't see why this syntax wouldn't
work.
> > How do you propose to implement this pseudo-class system where functions
> act like classes in only one case, when fetching this fake class constant?
> >
> > I'm not: `::function` is not a constant, it would be recognized by the
> parser directly.
>
> Right, but at least under the current parser, you couldn’t do that, to the
> best of my knowledge. I think using ::function over-complicates things.
>
No clue how complicated `Foo::bar::function` gets with the current parser,
but if that's the problem, then I'd ask Nikic directly, as he may find an
easy solution if the AST-based parsing makes it into core.
That said, it is another option, just not one we could implement
> immediately or that I personally am particularly fond of.
>
My point here is consistency. I'd love to have the same kind of static
reference for classes and functions/methods. Even `::const` eventually, as
well as other symbols if anyone can think of them.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
