Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95153
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.169 as permitted sender)
To: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>
References: <CABdc3WpGQp+ZA6qSQs-ap5VHntH9tzDQOx333eiobsGxYs=DFQ@mail.gmail.com>
 <CAMUwpuQ9ZUdfziCXQAxuS3Drmh2vPSOkpvXf7cOg0xbdNEgD=g@mail.gmail.com>
 <d1abf6e8-4949-6239-2664-a39d956fab14@gmail.com>
 <f9eb5b0a-1031-ed08-08f3-c67be514436c@fleshgrinder.com>
 <11f9c899-77b4-da50-f0f7-dc2d16b1829c@gmail.com>
 <CAFp73Xv=J+L6kS7j4ebLD_Rk5_kj2tb7QQacv6u3QnYr7-j5_A@mail.gmail.com>
 <431d5b9c-15ef-9af8-7a55-b776b2dd22ad@gmail.com>
 <CAFp73XvZirJgHtBmVpD8KDJL=XiAQFC8-Zvu0zQt5raTJzckkA@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
Message-ID: <5d38c41d-f189-56d2-be58-d60be3fd1bd9@gmail.com>
Date: Sun, 14 Aug 2016 15:35:20 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0)
 Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAFp73XvZirJgHtBmVpD8KDJL=XiAQFC8-Zvu0zQt5raTJzckkA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Namespaces internal refactoring
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> A realization that needs to be made is that beginners would be using
> libraries that requires to make valid restrictions, preventing those
> beginners to mess up with code they shouldn't. So even if the use case
> is only valid for 0.01% of code producers, it might be valid for 20%+ of
> consumers.

I don't think PHP needs more bondage-and-discipline. If beginners "mess
up with code they shouldn't" that is usually, in my experience, a sign
of library authors not serving their use case well, and not implementing
functionality that they need. Either because they didn't know, or
because their opinion about user's needs differs from user's opinion
about their needs. In this case, I'm on the user's side. Hacker's ethos
is doing things other people think can't be done.

> It's about defensive programming.
> I never knew TopologicalSorter was used by several users until I
> actually broke its API. Imagine the frustration of all those developers
> with tight deadlines having to deal with a sudden breakage, because the
> language it too open to notify them about something shouldn't be used.

I'd rather say "imagine the frustration of all those developers that
rely on the library authors who are oblivious to their true needs and
still the developers at the mercy of them every day". I agree that can
be frustrating. The solution is not more detachment from the needs of
the users and more fencing out so these pesky users would have
absolutely no way to use my code in ways that I didn't foresee, because
I'm capable of foreseeing 100% of user's needs and if I'm not, it's
their fault. At least, I don't think it is.

> Every time someone questions me about the validity of private classes, I
> like to exercise replacing the term "private" with "final". Final is
> part of PHP language and it also there's non application that is
> prevented without it.

I think most of the usages of final are wrong too, and for the same
reasons. It's a claim you have foreseen all user's needs and they'd
never need anything else. It's usually wrong.

> modifier, https://mwop.net/blog/2012-06-28-oop-visibility.html history
> would be completely different.

There Matthew says pretty much what I say, so I agree:

I feel that frameworks and libraries should use private and final sparingly.

> That's not about preventing for no reason and it should be bypassed.
> It's about somehow telling users that something shouldn't be used at all.
> The amount of people that takes the wrong approach is insane, and any
> kind of prevention to do it is beneficial.

If the amount of people using your library in a wrong way is insane,
maybe something needs to be changed in the library? ;) If you build a
nice slick walkway and people keep walking over the grass 100 meters
aside, it may just be you've built the walkway in a wrong place.

> I managed big teams of development where I work, and controlling code
> produced by 40+ developers is not easy.
> Countless classes are marked as final and I bet hundreds would be final
> if I could.
> Handling a company source code is easy through code reviews, and also
> walk a few steps to ask why a certain class is final or (hypothetically,
> private).

Maybe it makes sense to a company which works on its own product, never
to be used by others, and has every use of the code tightly controlled,
foreseen and signed in triplicate with TPS reports on top. My opinion
though it is more of a burden than a benefit to an open-source
environment built on extending and modifying existing code.

> I've walked through several scenarios of peers coming to my desk asking
> to remove final because reasons and going out with a much simpler
> solution without the need to remove it.

That implies you are always smarter than any user of your classes and
have foreseen their need in advance before they even were aware of them.
It is nice to be a genius, unfortunately, there's only one of you, and
maybe another dozen of similar geniuses in existence (I'm certainly not
one of them, not even close). Others need to deal with situations where
their code is used in situations where they did not foresee 100% of
users' needs and some modification/extension should be made. Betting on
being a prophetical genius is usually a losing bet. Unless, of course,
you are. But I would rather prefer the flexibility of being able to
correct my mistakes and shortsightedness than betting on that. Which
means flexibility beats bondage-and-discipline.

> Problem of lack of Annotations support... I've tried several times, and
> made sure I was accessible enough to answer every situation or scenario
> Doctrine faced and reasons for every decision taken on the library.
> Still, people seem to ignore expertise and decide to take their own
> methods which only solves (I'll use your numbers now) 0.01% of use cases.

Unfortunately I am of opposite opinion - that the Doctrine needs -
important as they are - are 0.01% of all PHP user's needs. And the fact
that we don't have solution we could build on (again, you see the
leitmotif I'm harping on - being flexible instead of trying to be ideal
at the start and freezing there) because that solution won't serve *all*
the needs appears very unfortunate to me.

> When I mentioned allowing to assess imported classes, I mean this:
> 
> namespace Foo;
> 
> use Bar\Woo;
> 
> /**
>  * @Woo\Fuzz()
>  */
> class Lala {}
> 
> Annotation parser needs to understand what was "use"d, so it can
> properly refer to FQCN. That way, we need to somehow discover something

I see what you mean. This seems to be a problem because you are trying
to do compiler things without the support of the compiler. I'd say the
right solution is to let the compiler do these things...
-- 
Stas Malyshev
smalyshev@gmail.com