Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64815
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFDmeSSOEXqv+QHAq7Eu2nRz6dg8zTXPFDt7FdDV=Qk+2fuU3Q@mail.gmail.com>
References: <CAFDmeSSOEXqv+QHAq7Eu2nRz6dg8zTXPFDt7FdDV=Qk+2fuU3Q@mail.gmail.com>
Date: Thu, 10 Jan 2013 13:11:47 +0100
Message-ID: <CAH-PCH7xFB3DNzTRoY0NLevFKDU2Nw8RQAOJeHbdVE0s-Nroig@mail.gmail.com>
To: Nate Tuganov <it@cloudmill.ru>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=14dae934107144e4be04d2ee15b6
Subject: Re: [PHP-DEV] A remark about PHP's Vision and new things.
From: tyra3l@gmail.com (Ferenc Kovacs)

--14dae934107144e4be04d2ee15b6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 10, 2013 at 10:17 AM, Nate Tuganov <it@cloudmill.ru> wrote:

> Hello,
>
> Well, I've been reading internals for years and never replied. But I thin=
k
> this time I have to share my thoughts.
>
> First of all I understand Rasmus and Stas position on holding PHP as simp=
le
> as it is. It's great and in the same way it's wrong. As Anthony mentioned
> PHP evolves, and PHP is being used not only by designers who want to crea=
te
> a simple corp site which by the way move to Rails, but mostly by thousand=
s
> of web agencies, developers and senior developers who constantly using
> different languages and technologies. We have Ruby with all the sugar it
> gives, we have Java with all enterprise mess it has. And we have PHP.
>
> I don't think I need to advocate OOP here, and I agree with Rasmus that w=
e
> need to stay simple. But we don't need to copy all those things from Java
> for example, even Java world has Play! Framework which is great and gives
> simpleness to the developer. We all know how annotations are being used b=
y
> Symfony or Doctrine and I don't think we need to create all the mess it h=
as
> in Java world. We all know the problems it give, why not to eliminate it
> and create a new, PHP's vision of things. Right now all discussions are
> being held like we will never implement annotations because we need to co=
py
> it from Enterprise Java. But we don't need Java annotations, we need our
> own. Constantly decline great futures just because some designer wouldn't
> understand it is wrong by all means.
>
> PHP is great for web development, let's stick to it. Give us a chance to
> create frameworks, which can use Annotations, DI, IoC, Factories,
> Decorators and all others patterns to allow regular designer to create a
> simple site with few lines of code.
>
> --
> Kind Regards,
>
> Ignat Tuganov
> Chief Information Officer
>
> Office Phone: +7 (812) 640-8022
>
> E-Mail \ Gtalk: it@cloudmill.ru
>
> CloudMill LLC
> 191015, 3 K Furazhnyi Lane, office #317, Saint-Petersburg, Russia
>

hi,

another thing to keep in mind:
most PHP frameworks out there has a faster development cycle and less of an
userbase than us(as every PHP framework user is a PHP user ofc.), so if
they make a bad design decision it is usually easier for them to fix it and
it has less of an impact and they have more people with the ability to fix
up any technical problems, as it is reasonably easy to find somebody with
the neccessary skills and knowledge required to fix the problem.
of course now that we introduced the new release process, hopefully we will
have faster release cycles, and some of the popular frameworks started
planning/introducing LTS releases with longer support cycle.
but still, we have to be careful about what do we introduce to the
language, because we have to support it for at least like minor 3 releases(
we introduce it in 7.2, deprecate it in 7.3 and remove it in 8.0 for
example).
back in the early symfony days using Singletons everywhere seemed like a
good idea, currently the general consensus is that it is an anti-pattern,
and only in a handful of use-cases is it a good idea using it.
similar thing happened with ORMs, first ORM meant pretty much using the
activerecord pattern, now the general consensus seems to be to use the data
mapper pattern instead.
if we too eager to include new hip stuff, it can happen that we will get
stuck with a half-baked solution which we have to support years after that
the cool guys already moved to something else.
the other thing that I mentioned is the difference between the required
skills needed to fix up bad implementations:
there aren't that many people familiar with the php-internals (and this
isn't the easier skill to pick up, as we somehow lack in quality
documentation on the internals part), even less people are familiar with
the parser, ZendEngine, and APC.
just some of the recent examples:

   - traits was a nice RFC, complete patch, has an active author, years of
   discussion, and it still needed a huge amount of work/refact to make it
   play nicely with some edge-cases and with APC. (kudos to Stefan and
   Dmitiry)
   - the finally feature: it was almost completely rewritten after the RFC
   with the initial patch was voted and accepted (kudos to Laruence and Dmi=
try)
   - introducing generators also needed some love (a few segfaults in
   edge-cases AFAIR and making it work together with finally kudos to Nikit=
a
   and Dmitry).

So I think the current problems are the following:

   - users won't migrate to new php version until some of the top pecl exts
   having issues with the new version (apc was a really obvious showstopper
   for the php5.4 adoptation for example).
   - currently voting is more about wanting the feature or not, and not
   about wanting/accepting the feature with the current implementation. thi=
s
   can result in situations when something is accepted and merged, but it h=
as
   to be fixed/maintained, and that sucks when the work happens to require =
the
   help of those who voted no based on their understanding on the problems =
of
   the proposed rfc/patch.
   - we don't have enough QA exposure, so some of the problems will only
   surface after the first final release (the implementation problems of
   traits for example).
   - there are key areas where we lack active people (ZE, APC, etc.).
   - the previous (nonexistent) release process made us really slow on
   fixing/removing things:
   http://blog.roshambo.org/a-brief-unofficial-history-about-register_globa=
ls-in-php/(it
was removed in 5.4.0 which was released 2012 Marc 01.)  It took more
   than 10 years to remove it since the time it was first accepted as a bad
   decision to include.
   - the new release process allows/mandates planned and faster release
   cycles, but it also means that we can only remove features in major vers=
ion
   jumps, which would either result in more frequent major feature bumps or
   long gaps between times when we can remove features.
   - and yeah, I think that php means a lot of different things to a lot of
   different people, so most of the times there can and will be arguments
   whether or not it is a good idea or the 'php way' to include something. =
but
   as long as we resolve those conflicts in civil manners and not using som=
e
   kind of fallacy (or making intentionally confusing/incomplete RFCs and
   pushing through them the voting) it should be fine.

Sorry for the wall-of-text: 'If I Had More Time, I Would Have Written a
Shorter Letter'

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--14dae934107144e4be04d2ee15b6--