Debugging code ...

10 years ago by Lester Caine — view source

unread

On the basis of 'If it's not broken', what is actually broken, and what
is just a matter of 'I don't like that way of working'?

I have a working Annotation system that has not changed since I started
working with PHP. PHPEclise simple displays the information from the
docblock comments and allows me to open the relevant file. I can then
review the other functions available. I can update the material and have
even resorted to porting files and adding extra notes when trying to
decipher other peoples work.

The problem these days is that projects are stripping the docblock data
as 'not the modern way of doing things' and we end up with code that
does not work with the IDE. Fortunately DVCS systems have some other
advantages and one can cherry pick code changes while maintaining a
different style of working.

In addition to 'Annotation', there is a lot of discussion about adding
types into the code. Having moved to using arrays to pass data to
functions, the docblock material includes details on what is required in
the hash, something that you will never get from any of the current
discussions?

Just to add to the fun, PHPEclipse seems to have lost support and while
I have learnt enough Java in the past to fix a few little niggles,
currently it is unable to cope with a number of new developments in PHP
so I'm stuck on just what IS the next move ... While it would be nice to
get on with some new code, nothing is stable enough these days to allow
that :(

--
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

10 years ago by Florian Margaine — view source

unread

Hi,

On the basis of 'If it's not broken', what is actually broken, and what
is just a matter of 'I don't like that way of working'?

I have a working Annotation system that has not changed since I started
working with PHP. PHPEclise simple displays the information from the
docblock comments and allows me to open the relevant file. I can then
review the other functions available. I can update the material and have
even resorted to porting files and adding extra notes when trying to
decipher other peoples work.

The problem these days is that projects are stripping the docblock data
as 'not the modern way of doing things' and we end up with code that
does not work with the IDE. Fortunately DVCS systems have some other
advantages and one can cherry pick code changes while maintaining a
different style of working.

In addition to 'Annotation', there is a lot of discussion about adding
types into the code. Having moved to using arrays to pass data to
functions, the docblock material includes details on what is required in
the hash, something that you will never get from any of the current
discussions?

Just to add to the fun, PHPEclipse seems to have lost support and while
I have learnt enough Java in the past to fix a few little niggles,
currently it is unable to cope with a number of new developments in PHP
so I'm stuck on just what IS the next move ... While it would be nice to
get on with some new code, nothing is stable enough these days to allow
that :(

Right now, I'm afraid your emails looks like a rant more than anything
else. I'm absolutely certain that you have something interesting to say,
but the message just didn't get through. Could you elaborate?

--
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

--

Regards,

--
Florian Margaine

10 years ago by Lester Caine — view source

unread

On the basis of 'If it's not broken', what is actually broken, and what
is just a matter of 'I don't like that way of working'?

I have a working Annotation system that has not changed since I started
working with PHP. PHPEclise simple displays the information from the
docblock comments and allows me to open the relevant file. I can then
review the other functions available. I can update the material and have
even resorted to porting files and adding extra notes when trying to
decipher other peoples work.

The problem these days is that projects are stripping the docblock data
as 'not the modern way of doing things' and we end up with code that
does not work with the IDE. Fortunately DVCS systems have some other
advantages and one can cherry pick code changes while maintaining a
different style of working.

In addition to 'Annotation', there is a lot of discussion about adding
types into the code. Having moved to using arrays to pass data to
functions, the docblock material includes details on what is required in
the hash, something that you will never get from any of the current
discussions?

Just to add to the fun, PHPEclipse seems to have lost support and while
I have learnt enough Java in the past to fix a few little niggles,
currently it is unable to cope with a number of new developments in PHP
so I'm stuck on just what IS the next move ... While it would be nice to
get on with some new code, nothing is stable enough these days to allow
that :(

Just that what many of us have used for years is coming under increasing
pressure as other people promote their own way of working. In the past
we have been able to co-exist, but it is becoming increasingly difficult
as people 'update' coding styles. Anything that is added to the 'core'
WILL be used to update third party code, but the rest of the
infrastructure is simply not keeping up.

--
Lester Caine - G8HFL

10 years ago by Florian Margaine — view source

unread

Hi,

On the basis of 'If it's not broken', what is actually broken, and
what
is just a matter of 'I don't like that way of working'?

I have a working Annotation system that has not changed since I
started
working with PHP. PHPEclise simple displays the information from the
docblock comments and allows me to open the relevant file. I can then
review the other functions available. I can update the material and
have
even resorted to porting files and adding extra notes when trying to
decipher other peoples work.

The problem these days is that projects are stripping the docblock
data
as 'not the modern way of doing things' and we end up with code that
does not work with the IDE. Fortunately DVCS systems have some other
advantages and one can cherry pick code changes while maintaining a
different style of working.

In addition to 'Annotation', there is a lot of discussion about
adding
types into the code. Having moved to using arrays to pass data to
functions, the docblock material includes details on what is
required in
the hash, something that you will never get from any of the current
discussions?

Just to add to the fun, PHPEclipse seems to have lost support and
while
I have learnt enough Java in the past to fix a few little niggles,
currently it is unable to cope with a number of new developments in
PHP
so I'm stuck on just what IS the next move ... While it would be
nice to
get on with some new code, nothing is stable enough these days to
allow
that :(
Right now, I'm afraid your emails looks like a rant more than anything
else. I'm absolutely certain that you have something interesting to say,
but the message just didn't get through. Could you elaborate?
Just that what many of us have used for years is coming under increasing
pressure as other people promote their own way of working. In the past
we have been able to co-exist, but it is becoming increasingly difficult
as people 'update' coding styles. Anything that is added to the 'core'
WILL be used to update third party code, but the rest of the
infrastructure is simply not keeping up.

I'm sorry... I may be stupid. I'm not sure I understand what you want to
say.

I have a guess though: are you saying that, for example, PHPEclipse at its
version from 2008 can't cope up with PHP at its version from 2014?

--
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

--

Regards,

--
Florian Margaine

10 years ago by Lester Caine — view source

unread

Hi,

On Tue, Nov 4, 2014 at 2:28 PM, Lester Caine <lester@lsces.co.uk
mailto:lester@lsces.co.uk> wrote:

>     On the basis of 'If it's not broken', what is actually broken,
and what
>     is just a matter of 'I don't like that way of working'?
>
>     I have a working Annotation system that has not changed since
I started
>     working with PHP. PHPEclise simple displays the information
from the
>     docblock comments and allows me to open the relevant file. I
can then
>     review the other functions available. I can update the
material and have
>     even resorted to porting files and adding extra notes when
trying to
>     decipher other peoples work.
>
>     The problem these days is that projects are stripping the
docblock data
>     as 'not the modern way of doing things' and we end up with
code that
>     does not work with the IDE. Fortunately DVCS systems have some
other
>     advantages and one can cherry pick code changes while
maintaining a
>     different style of working.
>
>     In addition to 'Annotation', there is a lot of discussion
about adding
>     types into the code. Having moved to using arrays to pass data to
>     functions, the docblock material includes details on what is
required in
>     the hash, something that you will never get from any of the
current
>     discussions?
>
>     Just to add to the fun, PHPEclipse seems to have lost support
and while
>     I have learnt enough Java in the past to fix a few little niggles,
>     currently it is unable to cope with a number of new
developments in PHP
>     so I'm stuck on just what IS the next move ... While it would
be nice to
>     get on with some new code, nothing is stable enough these days
to allow
>     that :(
>
> Right now, I'm afraid your emails looks like a rant more than anything
> else. I'm absolutely certain that you have something interesting
to say,
> but the message just didn't get through. Could you elaborate?

Just that what many of us have used for years is coming under increasing
pressure as other people promote their own way of working. In the past
we have been able to co-exist, but it is becoming increasingly difficult
as people 'update' coding styles. Anything that is added to the 'core'
WILL be used to update third party code, but the rest of the
infrastructure is simply not keeping up.

I'm sorry... I may be stupid. I'm not sure I understand what you want to
say.
I have a guess though: are you saying that, for example, PHPEclipse at
its version from 2008 can't cope up with PHP at its version from 2014?

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. The problem with keeping the available IDE's up to
date with the current code is secondary and PHPEclipse just happens to
be my preference, but if I switch to other options I find similar lag in
support for key features. Learning a new platform is a bigger stopper
currently than living with the holes and I will probably fix the problem
with :: before giving up in and changing ... but it would be nice not to
have the hassle.

--
Lester Caine - G8HFL

10 years ago by Peter Lind — view source

unread

It sounds like you're suggesting that all work on PHP that does not boil
down to bug fixes be stopped.

I'd suggest an alternative: fork PHP and only merge bugfixes in to your own
version. Best of both worlds, you get to keep your beloved PHP pristine
without any of the cumbersome new features, and the rest of us can enjoy an
evolving language.

Hi,

On Tue, Nov 4, 2014 at 2:28 PM, Lester Caine <lester@lsces.co.uk
mailto:lester@lsces.co.uk> wrote:
>     On the basis of 'If it's not broken', what is actually broken,
and what
>     is just a matter of 'I don't like that way of working'?
>
>     I have a working Annotation system that has not changed since
I started
>     working with PHP. PHPEclise simple displays the information
from the
>     docblock comments and allows me to open the relevant file. I
can then
>     review the other functions available. I can update the
material and have
>     even resorted to porting files and adding extra notes when
trying to
>     decipher other peoples work.
>
>     The problem these days is that projects are stripping the
docblock data
>     as 'not the modern way of doing things' and we end up with
code that
>     does not work with the IDE. Fortunately DVCS systems have some
other
>     advantages and one can cherry pick code changes while
maintaining a
>     different style of working.
>
>     In addition to 'Annotation', there is a lot of discussion
about adding
>     types into the code. Having moved to using arrays to pass data
to
>     functions, the docblock material includes details on what is
required in
>     the hash, something that you will never get from any of the
current
>     discussions?
>
>     Just to add to the fun, PHPEclipse seems to have lost support
and while
>     I have learnt enough Java in the past to fix a few little
niggles,
>     currently it is unable to cope with a number of new
developments in PHP
>     so I'm stuck on just what IS the next move ... While it would
be nice to
>     get on with some new code, nothing is stable enough these days
to allow
>     that :(
>
> Right now, I'm afraid your emails looks like a rant more than
anything
> else. I'm absolutely certain that you have something interesting
to say,
> but the message just didn't get through. Could you elaborate?

Just that what many of us have used for years is coming under
increasing
pressure as other people promote their own way of working. In the
past
we have been able to co-exist, but it is becoming increasingly
difficult
as people 'update' coding styles. Anything that is added to the
'core'
WILL be used to update third party code, but the rest of the
infrastructure is simply not keeping up.
I'm sorry... I may be stupid. I'm not sure I understand what you want to
say.
I have a guess though: are you saying that, for example, PHPEclipse at
its version from 2008 can't cope up with PHP at its version from 2014?
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. The problem with keeping the available IDE's up to
date with the current code is secondary and PHPEclipse just happens to
be my preference, but if I switch to other options I find similar lag in
support for key features. Learning a new platform is a bigger stopper
currently than living with the holes and I will probably fix the problem
with :: before giving up in and changing ... but it would be nice not to
have the hassle.

--
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

--

--
<hype>
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
</hype

10 years ago by Lester Caine — view source

unread

I'd suggest an alternative: fork PHP and only merge bugfixes in to your
own version. Best of both worlds, you get to keep your beloved PHP
pristine without any of the cumbersome new features, and the rest of us
can enjoy an evolving language.

In hind sight that is perhaps a choice that SHOULD have been made when
e_strict was introduced. I still have a lot of code that will not run on
a stock PHP5.4 installation but is running live sites quite happily on
an older setup and care has to be taken of any security problems found
anyway. The evolution I am still awaiting is to be able to use the
unicode material I have in the databases directly in PHP arrays rather
than having to take care of ordering externally ... and that perhaps is
the only reason I didn't freeze ...

--
Lester Caine - G8HFL

10 years ago by Kristopher — view source

unread

On Tue Nov 04 2014 at 9:31:06 AM Lester Caine lester@lsces.co.uk 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.

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.

It's also pretty arrogant to assume your workflow and setup will work for
everyone, and that they should just deal with it.

10 years ago by Lester Caine — view source

unread

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 :(

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?

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?

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?

--
Lester Caine - G8HFL

10 years ago by Chris Wright — view source

unread

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

10 years ago by Lester Caine — view source

unread

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...

It is not the PHP infrastructure which is the problem here ... it is
everything else that PHP relies on to get it's output to the end user.
I've had two updates today on Firefox (and one has broken new tab
function!), and most of the legacy sites have had to have some changes
to make them work cleanly with 'modern browsers'. But even in the PHP
domain, PHP5.3 and 5.4 can hardly be called minor updates. The both
require substantial work to ensure sites remain working after an upgrade.

phpng is the sort of major upgrade we ARE all looking for, and was
originally road mapped as not affecting the core language? That is
making PHP better, and there ARE ports of PHP with their own take on how
things should change language wise? All I am asking is that
consideration is given to the full effect on backwards compatibility by
some of the non-essential changes. 'Does not have' is often an incorrect
statement when you widen the pool of resources and we should be
contesting those claims anyway.

The point about the debuggers was that THEY do exist as separate tools
and I think some of the other features being requested would also work
better as separate tools.

Debugging code ...

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL