Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78646
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.178 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <5458F9DA.7060308@lsces.co.uk>
References: <5458CEAF.7060204@lsces.co.uk>
	<CABRjmp_UJz7BExqFyXdB35-KQ3BANPV0UqKhJz64njFzEKyNvA@mail.gmail.com>
	<5458D492.9040207@lsces.co.uk>
	<CABRjmp_EGV+esSi7u9jRL0n+h1O63f4FLr5_0c_yT0FETZKq-w@mail.gmail.com>
	<5458E306.50006@lsces.co.uk>
	<CAF9U7z8v_HF7cx=Lndufq67bvb+AsAEn7Y1ZvDTwA-_+-ZxY7w@mail.gmail.com>
	<5458F9DA.7060308@lsces.co.uk>
Date: Tue, 4 Nov 2014 16:25:43 +0000
Message-ID: <CAGAGxbbyTDHGMORZFv8HdRi9UvNnnGykM8U0NcmmvyZw0y=etw@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c14c242af34b05070aea41
Subject: Re: [PHP-DEV] Debugging code ...
From: cw@daverandom.com (Chris Wright)

--001a11c14c242af34b05070aea41
Content-Type: text/plain; charset=UTF-8

On 4 November 2014 16:07, Lester Caine <lester@lsces.co.uk> wrote:

> On 04/11/14 14:51, Kristopher wrote:
> >     Every IDE I've used has always working nicely with docblock
> annotation
> >     and typing and has provided the facilities people seem to think
> should
> >     be built in to PHP.
> >
> > You understand you don't have to use these new features, right? You can
> > continue using comment-driven DocBlocks and not use any typing. They are
> > purely optional features.
> That argument falls flat on it's face when primary libraries upgrade to
> use 'the new standards' at the expense of compatibility with previous
> practices. Keeping compatible versions running just complicates matters
> when the target infrastructure is changing daily :(


An 18 month release cycle for minors and over a decade since the last major
is hardly "daily". You do not need to update the libraries when they start
to use the new language features, but if you want to use the new library
features, and those features leverage new language features, then you need
to update the runtime as well. If you don't want/need the shiny new
features, just don't upgrade. PHP is hardly the only ecosystem where this
is true...


> > To advocate not adding the features simply because you don't want them,
> > when they are plenty of other people who do want them and do find a use
> > for them, is pretty selfish.
> Have I said ANYTHING about not fixing bug such as perhaps making PHP
> work with Unicode properly?


One man's bugfix is another man's feature. If you want one of the new shiny
things you have to live with the other new shiny things that others want
(and no-one is making you use any of these other things).


>
> > It's also pretty arrogant to assume your workflow and setup will work
> > for everyone, and that they should just deal with it.
> All I am saying is that many of the complaints being made by others that
> PHP is missing 'important facilities' has a counter that in many cases
> there is no problem if you use a different method of working.
>
> Some of us do perhaps need to document better the alternative way of
> doing things, and I DO think that loading down the core engine with
> facilities which are better provided by secondary tools is the wrong
> approach. However since PHP has a modular structure, it should also be
> possible to leave out components that are not essential to actually run
> the code?
>

This almost precisely describes extensions, we already have this. But you
cannot make *language* features (syntax etc) into extensions or it would be
chaos and nothing would interoperate with anything. There *has* to be a
stable base that everything can rely on.


> It is perhaps just making a case for what is needed to improve the
> functionality of the engine, and what - like the debuggers - can be kept
> as non-essential secondary tools?
>

Both of these already are non-essential secondary tools. xdebug is an
extension, which you do not have to install and isn't even bundled with
PHP. phpdbg is an entirely new SAPI which you are free to ignore, none of
the existing SAPIs rely on it in order to function, their functionality has
not changed, it is a totally separate entry point. Even if we started
bundling PHP with xdebug tomorrow, you need not ever use it if you don't
want to, since absolutely nobody anywhere would start shipping PHP with
xdebug compiled in as a static module, it would remain as a shared
extension and you could simply disabled it.

Likewise, if annotations existed, you could simply not use them if you
didn't want any of the *new* functionality they would provide - they would
not stop anything from working.


>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a11c14c242af34b05070aea41--