Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95161
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5d38c41d-f189-56d2-be58-d60be3fd1bd9@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>
 <5d38c41d-f189-56d2-be58-d60be3fd1bd9@gmail.com>
Date: Sun, 14 Aug 2016 20:42:45 -0400
Message-ID: <CAFp73XvF8_e98BuSt7uWKhomnvBbbinh=x06rCf0a4GJsKvr4w@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c135984f11fbf053a1183cd
Subject: Re: [PHP-DEV] Namespaces internal refactoring
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--94eb2c135984f11fbf053a1183cd
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Sun, Aug 14, 2016 at 6:35 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> 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 a valid point of view, indeed.
But thinking from a different perspective, if you are using a tool that
does X, users shouldn't rely on Y to complete their job. Specially if Y is
already on a namespace marked as "Internal" with @private annotation and a
huge capital disclaimer that it was a private class.

It doesn't matter how much documentation you add, without language tooling
that prevents to use X as Y, all you can expect are weird use cases and
breakages, that re either not intended to work or are just not supposed to
be done at all. Like I always say "never underestimate someone's ignorance".


>
> > 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.
>

Taking from this perspective (and also inline with your initial comment),
what you are suggesting is basically break down common, reusable piece of
functionality on its own package. Yes, that is valid, and I have nothing
against it.
The lack of breaking X into smaller packages (such as decoupling Y) doesn't
mean users should use Y at will and suddenly expect/blame about API breaks.


>
> > 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.
>

Here you basically agreed with everything I said. I'm not saying every
single class should be private (or final), but you just agreed with Matthew
and I that there are valid use cases for each one.


>
> > 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.
>

It's always a balance between what you can do in such a small spare time
and benefits you get out of these contributions that you could use to get
your job done.
I could perfectly decouple 10 sub-packages out of ORM, but that only brings
more maintenance burden that will consume more time that I already don't
have.


>
> > 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.
>

Not really. I worked as Chief Architect and controlling integration
conflicts consumed most of my time while designing and planning the
platform.
Every feature had critical technical architecture points highlighted and
another series of decisions to be made by developers. When handling large
volumes of traffic, some technology decisions are required in order to keep
business online, and some critical pieces of code were heavily controlled
by key developers.


>
> > 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.
>

By far I'm not the most genius person I've worked with. I tend to relate
this to scope knowledge and the amount of time invested during strategy,
architecting and planning a solution. If I spend 100h exercising edge cases
out of a solution, I may have covered a substantial amount of potential
problems that may come up by developers who are purely focused on
delivering a small feature.
That doesn't mean I have covered 100% of all edge cases, but surely I've
exercised things out of a solution more than others. If I haven't, I
wouldn't be doing my architect's job.

Anyway, this is already derailing into a completely separate topic. Let's
stick to the main subject, please.


>
> > 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.
>

Doctrine needs seems like a 0.01% of use cases, but they are also shared by
Symfony, Zend Framework and many other projects too.
We even downscaled a lot the suggested solution too, but it was ignored
somehow. For example, typed properties would reduce significantly our
implemented solution, because we'd rely on language support to the work for
us.

The only problem I find is that PHP is full of half-baked solutions. People
focus too much on a specific feature and do not consider a holistic
approach. Small example: people found it seriously cool to adopt ?Foo as a
nullable type. However, it complicated a lot the implementation of typed
properties (Joe had to work on a triple variable state to make it work).
Now implementation of typed properties was to blame, but I seriously think
it was the introduction of nullable types the culript.


>
> > 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...
>

Yes, yes and yes. When can we get that?
I'll again reinforce that library developers have to come up with creative
ways to handle lack of support in the language. That was just one example.
Instead, the language should offer proper support and let library
developers to come up with creative tools (and now creative ways) to
improve and ease end user's development.



> --
> Stas Malyshev
> smalyshev@gmail.com
>



-- 
Guilherme Blanco
Lead Architect at E-Block

--94eb2c135984f11fbf053a1183cd--