php-general Digest 6 Feb 2012 17:59:48 -0000 Issue 7677
Topics (messages 316465 through 316488):
Re: Headers on smart phone browsers
316465 by: Mari Masuda
316470 by: Jim Giner
316472 by: Marc Guay
Long Live GOTO
316466 by: Adam Richardson
316467 by: Tim Streater
316468 by: Adam Richardson
316469 by: Adam Richardson
316471 by: Robert Cummings
316473 by: Tim Streater
316474 by: Jim Giner
316475 by: Alain Williams
316476 by: Larry Martell
316477 by: Adam Richardson
316478 by: Alain Williams
316479 by: Adam Richardson
316480 by: Tim Streater
316481 by: Robert Cummings
316482 by: Robert Cummings
316483 by: Larry Martell
316484 by: Adam Richardson
316485 by: Adam Richardson
316486 by: Jim Giner
316487 by: Jim Giner
316488 by: Larry Martell
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On Feb 5, 2012, at 9:58 PM, Paul M Foster wrote:
[snip]
> 3) Bonus question: Is there a preferred method amongst coders to
> determine what type of environment is being browsed from, so as to serve
> up the proper type of page (desktop or smart phone version of a
> webpage)?
[snip]
You should read up on responsive web design.
http://www.alistapart.com/articles/responsive-web-design/ should get you
started. HTH!
--- End Message ---
--- Begin Message ---
Nice article!!
You should read up on responsive web design.
http://www.alistapart.com/articles/responsive-web-design/ should get you
started. HTH!=
--- End Message ---
--- Begin Message ---
> 1) Do smart phones use the same browsers as the desktop, or do they have
> their own stripped down versions of browsers?
Different browsers, some of which are worse than IE (see Blackberry).
> 2) When a browser broadcasts its header telling the server what kind of
> browser is involved, do they broadcast anything in the header to
> indicate that they're being run on a smart phone?
Nothing so specific or easy to identify as "i am a smartphone".
Depending on your target audience, simple regex checks for the strings
"iphone", "android", etc. can do the trick, but if you want specific
details about the device...
> 3) Bonus question: Is there a preferred method amongst coders to
> determine what type of environment is being browsed from, so as to serve
> up the proper type of page (desktop or smart phone version of a
> webpage)?
... the WURFL database and things akin to it or based on / stolen from
it can help parse the header string and return a plethora of
information about it (screen size, AJAX ability, markup capacity,
etc).
Marc
--- End Message ---
--- Begin Message ---
Hi,
While not purely focused on PHP, I toss this out to the group because I
believe there are some novel, interesting points regarding the potential
benefits of using the goto construct as implemented in PHP:
http://adamjonrichardson.com/2012/02/06/long-live-the-goto-statement/
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
--- End Message ---
--- Begin Message ---
On 06 Feb 2012 at 07:47, Adam Richardson <simples...@gmail.com> wrote:
> While not purely focused on PHP, I toss this out to the group because I
> believe there are some novel, interesting points regarding the potential
> benefits of using the goto construct as implemented in PHP:
>
> http://adamjonrichardson.com/2012/02/06/long-live-the-goto-statement/
Your val_nested() function looks like a straw-man to me. I've not used a goto
since I stopped writing in FORTRAN in 1978, and not missed it [1]. Neither do I
ever have deeply nested if-then-else - these are a good source of bugs. I
suppose the rest of your article might have been dealing with simplifying
val_nested() but TBH I wasn't interested enough to find out.
[1] Not quite true - a Pascal compiler I once had to use in 1983 lacked a
return statement, so I had to fake it by putting a 999: label at the end of the
function and goto-ing to that.
--
Cheers -- Tim
--- End Message ---
--- Begin Message ---
On Mon, Feb 6, 2012 at 4:07 AM, Tim Streater <t...@clothears.org.uk> wrote:
> On 06 Feb 2012 at 07:47, Adam Richardson <simples...@gmail.com> wrote:
>
> > While not purely focused on PHP, I toss this out to the group because I
> > believe there are some novel, interesting points regarding the potential
> > benefits of using the goto construct as implemented in PHP:
> >
> > http://adamjonrichardson.com/2012/02/06/long-live-the-goto-statement/
>
> Your val_nested() function looks like a straw-man to me. I've not used a
> goto since I stopped writing in FORTRAN in 1978, and not missed it [1].
> Neither do I ever have deeply nested if-then-else - these are a good source
> of bugs. I suppose the rest of your article might have been dealing with
> simplifying val_nested() but TBH I wasn't interested enough to find out.
>
I disagree that the nested function is a straw-man. I (just as the other
authors I'd linked to describing the "arrow" pattern of code) have seen
plenty of examples of similar code.
PHP provides a restricted implementation of the goto construct that, in my
opinion, can hold great value for developers.
Thanks for the feedback,
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
--- End Message ---
--- Begin Message ---
On Mon, Feb 6, 2012 at 4:25 AM, Adam Richardson <simples...@gmail.com>wrote:
> On Mon, Feb 6, 2012 at 4:07 AM, Tim Streater <t...@clothears.org.uk> wrote:
>
>> On 06 Feb 2012 at 07:47, Adam Richardson <simples...@gmail.com> wrote:
>>
>> > While not purely focused on PHP, I toss this out to the group because I
>> > believe there are some novel, interesting points regarding the potential
>> > benefits of using the goto construct as implemented in PHP:
>> >
>> > http://adamjonrichardson.com/2012/02/06/long-live-the-goto-statement/
>>
>> Your val_nested() function looks like a straw-man to me. I've not used a
>> goto since I stopped writing in FORTRAN in 1978, and not missed it [1].
>> Neither do I ever have deeply nested if-then-else - these are a good source
>> of bugs. I suppose the rest of your article might have been dealing with
>> simplifying val_nested() but TBH I wasn't interested enough to find out.
>>
>
> I disagree that the nested function is a straw-man. I (just as the other
> authors I'd linked to describing the "arrow" pattern of code) have seen
> plenty of examples of similar code.
>
> PHP provides a restricted implementation of the goto construct that, in my
> opinion, can hold great value for developers.
>
> Thanks for the feedback,
>
> Adam
>
Tim,
One quick follow-up. I'd thoroughly enjoy viewing a refactored version of
the val_nested() function from you (or anyone one else on the list) to see
the techniques PHP users tend to use to avoid the deep nesting.
That would be very useful in terms of properly evaluating the range of the
possible refactoring options and PHP user preferences.
Thanks again,
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
--- End Message ---
--- Begin Message ---
On 12-02-06 04:07 AM, Tim Streater wrote:
On 06 Feb 2012 at 07:47, Adam Richardson<simples...@gmail.com> wrote:
While not purely focused on PHP, I toss this out to the group because I
believe there are some novel, interesting points regarding the potential
benefits of using the goto construct as implemented in PHP:
http://adamjonrichardson.com/2012/02/06/long-live-the-goto-statement/
Your val_nested() function looks like a straw-man to me. I've not used a goto
since I stopped writing in FORTRAN in 1978, and not missed it [1]. Neither do I
ever have deeply nested if-then-else - these are a good source of bugs. I
suppose the rest of your article might have been dealing with simplifying
val_nested() but TBH I wasn't interested enough to find out.
[1] Not quite true - a Pascal compiler I once had to use in 1983 lacked a
return statement, so I had to fake it by putting a 999: label at the end of the
function and goto-ing to that.
Goto has it's uses, demonizing it due to the poor implementation and
misuse of it's same-named historical counterparts is an exercise in
closed-mindedness. Goto can really shine in parsers and various other
scenarios. While the example shown may be contrived it doesn't miss the
point. Since goto cannot jump out of the function nor jump into the
function it is well constrained to provide readability while eliminating
complexity. Additionally, it is quite likely that it is more optimal. A
single jump target versus one or more state variables to control nested
conditionals or loops results in faster execution (also important for
parsers).
I've had a strong opinion on goto for a very long time. I was one of the
proponents who argued on internals for its inclusion several years ago.
I stand by its utility and refer the reader to the fact that many open
source projects, especially ones that use some kind of parser, have goto
hidden within their implementation. You can find it in the C code for
the PHP, MySQL, and Apache to name a few easily recognizable projects.
Cheers,
Rob.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.
--- End Message ---
--- Begin Message ---
On 06 Feb 2012 at 15:05, Robert Cummings <rob...@interjinn.com> wrote:
> I've had a strong opinion on goto for a very long time. I was one of the
> proponents who argued on internals for its inclusion several years ago.
> I stand by its utility and refer the reader to the fact that many open
> source projects, especially ones that use some kind of parser, have goto
> hidden within their implementation. You can find it in the C code for
> the PHP, MySQL, and Apache to name a few easily recognizable projects.
All of which is no doubt true but that doesn't mean I have to like it, although
obviously I'll have to put up with it. Anyway, discussions of this sort tend to
be, or become, futile.
--
Cheers -- Tim
--- End Message ---
--- Begin Message ---
NO "GO"!
As one who started back in the 70's with old style coding that utilized GoTo
in Cobol, Fortran, etc. and had to deal with "spaghetti code" written by
even earlier developers who never considered that someone else would have to
maintain their code, I feel strongly that GoTo is not to be used.
There are many ways of avoiding the perceived need for a GoTo statement.
The 'Break' is one in PHP as is the 'Continue'. Better instruction in
programming since the 70's has taught beginning coders the value of
well-structured code using function calls and distinct paragraphs (if you
will) of code that help to structure the entire process into manageable
chunks to facilitate understanding and maintenance. Random GoTos
interspersed into code because a designer just hasn't taken the time to
write it well is just not smart. Think of a well-written article in a
journal or newspaper. Do you think that the author just threw it together
and the points to be made just fell out of it? No - that writer probably
spent a good amount of time re-working his first draft into second and third
drafts before getting his thoughts and words in the right order to
facilitate the presentation of the ideas he was trying to communicate. The
same process can and should be brought into play when writing code and in
that way produce a quality product that will stand the test of time and lend
itself easily to necessary improvements when needed.
My $.02.
"Adam Richardson" <simples...@gmail.com> wrote in message
news:CAC6CJqYLdqSih0+v=x78lnb_wun7sqmctkxdc0790th7c-c...@mail.gmail.com...
> Hi,
>
> While not purely focused on PHP, I toss this out to the group because I
> believe there are some novel, interesting points regarding the potential
> benefits of using the goto construct as implemented in PHP:
>
>
--- End Message ---
--- Begin Message ---
On Mon, Feb 06, 2012 at 11:12:53AM -0500, Jim Giner wrote:
> NO "GO"!
> As one who started back in the 70's with old style coding that utilized GoTo
> in Cobol, Fortran, etc. and had to deal with "spaghetti code" written by
> even earlier developers who never considered that someone else would have to
> maintain their code, I feel strongly that GoTo is not to be used.
I remember being faced with spaghetti code 35 odd years ago - yes, horrible.
But what do we mean by ''spaghetti code'' ? I remember code where every 3rd
statement was some form of GOTO - yuck!
One very desirable feature of code is that it be clear, ie: lucid, able to be
understood by others. Too many GOTO statements and it is hard.
However: a few GOTOs can make things clearer. Think of a function that can fail
in several different places (eg data validation, ...). But it is reading a file
which needs to be closed before the function returns. I have seen code where
some $IsError variable is tested in many places to see if things should be done.
That is just as bad as lots of GOTO -- often when having to write something like
that I will have a GOTO (in several places) to the bottom of the function that
closes the file and returns failure.
That is much clearer than extra variables.
If I survey my code I find that I use one GOTO in about 4,000 lines of code -
that I do not find excessive.
There are, however, people who consider any GOTO as communion with the devil.
IMHO: not so - if used sparingly.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h>
--- End Message ---
--- Begin Message ---
On Mon, Feb 6, 2012 at 9:23 AM, Alain Williams <a...@phcomp.co.uk> wrote:
> On Mon, Feb 06, 2012 at 11:12:53AM -0500, Jim Giner wrote:
>> NO "GO"!
>> As one who started back in the 70's with old style coding that utilized GoTo
>> in Cobol, Fortran, etc. and had to deal with "spaghetti code" written by
>> even earlier developers who never considered that someone else would have to
>> maintain their code, I feel strongly that GoTo is not to be used.
>
> I remember being faced with spaghetti code 35 odd years ago - yes, horrible.
> But what do we mean by ''spaghetti code'' ? I remember code where every 3rd
> statement was some form of GOTO - yuck!
>
> One very desirable feature of code is that it be clear, ie: lucid, able to be
> understood by others. Too many GOTO statements and it is hard.
>
> However: a few GOTOs can make things clearer. Think of a function that can
> fail
> in several different places (eg data validation, ...). But it is reading a
> file
> which needs to be closed before the function returns. I have seen code where
> some $IsError variable is tested in many places to see if things should be
> done.
> That is just as bad as lots of GOTO -- often when having to write something
> like
> that I will have a GOTO (in several places) to the bottom of the function that
> closes the file and returns failure.
>
> That is much clearer than extra variables.
>
> If I survey my code I find that I use one GOTO in about 4,000 lines of code -
> that I do not find excessive.
>
> There are, however, people who consider any GOTO as communion with the devil.
> IMHO: not so - if used sparingly.
Just for another data point, the FAA does not allow gotos in any code
that goes into an airplane.
--- End Message ---
--- Begin Message ---
On Mon, Feb 6, 2012 at 10:05 AM, Robert Cummings <rob...@interjinn.com>wrote:
> On 12-02-06 04:07 AM, Tim Streater wrote:
>
>> On 06 Feb 2012 at 07:47, Adam
>> Richardson<simpleshot@gmail.**com<simples...@gmail.com>>
>> wrote:
>>
>> While not purely focused on PHP, I toss this out to the group because I
>>> believe there are some novel, interesting points regarding the potential
>>> benefits of using the goto construct as implemented in PHP:
>>>
>>> http://adamjonrichardson.com/**2012/02/06/long-live-the-goto-**
>>> statement/<http://adamjonrichardson.com/2012/02/06/long-live-the-goto-statement/>
>>>
>>
>> Your val_nested() function looks like a straw-man to me. I've not used a
>> goto since I stopped writing in FORTRAN in 1978, and not missed it [1].
>> Neither do I ever have deeply nested if-then-else - these are a good source
>> of bugs. I suppose the rest of your article might have been dealing with
>> simplifying val_nested() but TBH I wasn't interested enough to find out.
>>
>> [1] Not quite true - a Pascal compiler I once had to use in 1983 lacked a
>> return statement, so I had to fake it by putting a 999: label at the end of
>> the function and goto-ing to that.
>>
>
> Goto has it's uses, demonizing it due to the poor implementation and
> misuse of it's same-named historical counterparts is an exercise in
> closed-mindedness. Goto can really shine in parsers and various other
> scenarios. While the example shown may be contrived it doesn't miss the
> point. Since goto cannot jump out of the function nor jump into the
> function it is well constrained to provide readability while eliminating
> complexity. Additionally, it is quite likely that it is more optimal. A
> single jump target versus one or more state variables to control nested
> conditionals or loops results in faster execution (also important for
> parsers).
>
> I've had a strong opinion on goto for a very long time. I was one of the
> proponents who argued on internals for its inclusion several years ago. I
> stand by its utility and refer the reader to the fact that many open source
> projects, especially ones that use some kind of parser, have goto hidden
> within their implementation. You can find it in the C code for the PHP,
> MySQL, and Apache to name a few easily recognizable projects.
>
> Cheers,
> Rob.
All excellent points, Robert.
Tim mentioned that my example was a straw-man, and you mentioned it was
contrived. Actually, it's a refactoring of a real function in my web
framework that I've committed to trunk and going to use for a while (it's
functionally inspired, and having the ability to store and retrieve
immutable values is quite handy in this situation.)
I like experimenting with different approaches (my background is in
cognitive psychology), and there's certainly research to show that deeply
nested ifs are problematic, cognitively speaking. Then, there are the other
techniques mentioned in the blog post to deal with them (guard clauses,
pulling out functions, grouping conditions), but they have they're issues,
too, in terms of processing (they can hurt proximity of related concepts,
forcing programmers to work against the mental model they've built up of a
problem, etc.) There are going to be issues with the goto approach I took
to refactoring the function, too, but I'm keenly interested in playing
around with it a while and letting the evidence accrue over time. I've read
many, many sources that seem to reject ANY approach using GOTO even without
properly evaluating its use within a language like PHP that offers some
beneficial restrictions.
Thanks for the insights (and I'm glad you pushed for the construct :)
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
--- End Message ---
--- Begin Message ---
On Mon, Feb 06, 2012 at 09:28:10AM -0700, Larry Martell wrote:
> On Mon, Feb 6, 2012 at 9:23 AM, Alain Williams <a...@phcomp.co.uk> wrote:
> > If I survey my code I find that I use one GOTO in about 4,000 lines of code
> > -
> > that I do not find excessive.
> >
> > There are, however, people who consider any GOTO as communion with the
> > devil.
> > IMHO: not so - if used sparingly.
>
> Just for another data point, the FAA does not allow gotos in any code
> that goes into an airplane.
And your point is ?
It just means that someone in the FAA does not like GOTO.
If you can come up with their reasoned argument for the ban I will look at it,
but without that the data point does not have much value - IMHO.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h>
--- End Message ---
--- Begin Message ---
On Mon, Feb 6, 2012 at 11:28 AM, Larry Martell
<la...@software-horizons.com>wrote:
> On Mon, Feb 6, 2012 at 9:23 AM, Alain Williams <a...@phcomp.co.uk> wrote:
> > On Mon, Feb 06, 2012 at 11:12:53AM -0500, Jim Giner wrote:
> >> NO "GO"!
> >> As one who started back in the 70's with old style coding that utilized
> GoTo
> >> in Cobol, Fortran, etc. and had to deal with "spaghetti code" written by
> >> even earlier developers who never considered that someone else would
> have to
> >> maintain their code, I feel strongly that GoTo is not to be used.
> >
> > I remember being faced with spaghetti code 35 odd years ago - yes,
> horrible.
> > But what do we mean by ''spaghetti code'' ? I remember code where every
> 3rd
> > statement was some form of GOTO - yuck!
> >
> > One very desirable feature of code is that it be clear, ie: lucid, able
> to be
> > understood by others. Too many GOTO statements and it is hard.
> >
> > However: a few GOTOs can make things clearer. Think of a function that
> can fail
> > in several different places (eg data validation, ...). But it is
> reading a file
> > which needs to be closed before the function returns. I have seen code
> where
> > some $IsError variable is tested in many places to see if things should
> be done.
> > That is just as bad as lots of GOTO -- often when having to write
> something like
> > that I will have a GOTO (in several places) to the bottom of the
> function that
> > closes the file and returns failure.
> >
> > That is much clearer than extra variables.
> >
> > If I survey my code I find that I use one GOTO in about 4,000 lines of
> code -
> > that I do not find excessive.
> >
> > There are, however, people who consider any GOTO as communion with the
> devil.
> > IMHO: not so - if used sparingly.
>
> Just for another data point, the FAA does not allow gotos in any code
> that goes into an airplane.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Can I have the source for this so I can read the rationale? I'm curious
which language implementation it's referencing (C, Ada, etc.) and what
restrictions the language places on the construct. Again, the PHP version
of the construct is beneficially quite restrictive. For instance, some
people don't like giving programmers access to pointers just because you
can get into so much trouble with them, but I wonder if they'd be concerned
about Go's pointers, which don't allow pointer arithmetic, limiting one are
of potential trouble:
http://golang.org/doc/go_for_cpp_programmers.html#Conceptual_Differences
Interesting.
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
--- End Message ---
--- Begin Message ---
On 06 Feb 2012 at 09:48, Adam Richardson <simples...@gmail.com> wrote:
> On Mon, Feb 6, 2012 at 4:25 AM, Adam Richardson <simples...@gmail.com>wrote:
>
>> On Mon, Feb 6, 2012 at 4:07 AM, Tim Streater <t...@clothears.org.uk> wrote:
>> I disagree that the nested function is a straw-man. I (just as the other
>> authors I'd linked to describing the "arrow" pattern of code) have seen
>> plenty of examples of similar code.
I guess what I meant was, that I'd never have written it that way in the first
place, so as an example it felt contrived. Amateurs or people with no training
(in particular physicists at CERN 40 years ago) should be kept well clear of
the goto. I'd probably write your function like this:
function val_nested ($name = null, $value = null, $is_mutable = false)
{
static $values = array();
static $mutables = array();
if ($name===null) return $values;
if ($value===null) return isset($values[$name]) ? $values[$name] : null;
if (isset($values[$name]))
{
if (!$val_is_mutable = in_array($name, $mutables)) // Set existing
value
{
$msg = 'The value "' . $name . '" is immutable and has already
been set to ' . $values[$name] . '.';
throw new Exception ($msg);
}
return $values[$name] = $value;
}
if ($is_mutable) $mutables[] = $name; // Set new value
$values[$name] = $value;
return $value;
}
I always add blank lines for clarity. Remove those and the above is 30% shorter
than yours - as far as I could tell, none of the else clauses was required.
My approach is:
1) deal with the trivial and error cases first
2) deal with the real work next
--
Cheers -- Tim
--- End Message ---
--- Begin Message ---
On 12-02-06 11:58 AM, Tim Streater wrote:
On 06 Feb 2012 at 09:48, Adam Richardson<simples...@gmail.com> wrote:
On Mon, Feb 6, 2012 at 4:25 AM, Adam Richardson<simples...@gmail.com>wrote:
On Mon, Feb 6, 2012 at 4:07 AM, Tim Streater<t...@clothears.org.uk> wrote:
I disagree that the nested function is a straw-man. I (just as the other
authors I'd linked to describing the "arrow" pattern of code) have seen
plenty of examples of similar code.
I guess what I meant was, that I'd never have written it that way in the first
place, so as an example it felt contrived. Amateurs or people with no training
(in particular physicists at CERN 40 years ago) should be kept well clear of
the goto. I'd probably write your function like this:
function val_nested ($name = null, $value = null, $is_mutable = false)
{
static $values = array();
static $mutables = array();
if ($name===null) return $values;
if ($value===null) return isset($values[$name]) ? $values[$name] : null;
[-- SNIPP --]
I always add blank lines for clarity. Remove those and the above is 30% shorter
than yours - as far as I could tell, none of the else clauses was required.
My approach is:
1) deal with the trivial and error cases first
Some say you should never return early from a function... I too think
that early returns can improve the readability of a function--
especially if they are short snippets of logic that clearly indicate the
reason for an early exit (usually edge case constraints).
:)
Cheers,
Rob.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.
--- End Message ---
--- Begin Message ---
On 12-02-06 11:35 AM, Alain Williams wrote:
On Mon, Feb 06, 2012 at 09:28:10AM -0700, Larry Martell wrote:
On Mon, Feb 6, 2012 at 9:23 AM, Alain Williams<a...@phcomp.co.uk> wrote:
If I survey my code I find that I use one GOTO in about 4,000 lines of code -
that I do not find excessive.
There are, however, people who consider any GOTO as communion with the devil.
IMHO: not so - if used sparingly.
Just for another data point, the FAA does not allow gotos in any code
that goes into an airplane.
And your point is ?
It just means that someone in the FAA does not like GOTO.
If you can come up with their reasoned argument for the ban I will look at it,
but without that the data point does not have much value - IMHO.
The date for when the ban was imposed might be interesting too...
perhaps it hasn't been revisited since the 70s.
Cheers,
Rob.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.
--- End Message ---
--- Begin Message ---
On Mon, Feb 6, 2012 at 9:50 AM, Adam Richardson <simples...@gmail.com> wrote:
> On Mon, Feb 6, 2012 at 11:28 AM, Larry Martell
> <la...@software-horizons.com>wrote:
>
>> On Mon, Feb 6, 2012 at 9:23 AM, Alain Williams <a...@phcomp.co.uk> wrote:
>> > On Mon, Feb 06, 2012 at 11:12:53AM -0500, Jim Giner wrote:
>> >> NO "GO"!
>> >> As one who started back in the 70's with old style coding that utilized
>> GoTo
>> >> in Cobol, Fortran, etc. and had to deal with "spaghetti code" written by
>> >> even earlier developers who never considered that someone else would
>> have to
>> >> maintain their code, I feel strongly that GoTo is not to be used.
>> >
>> > I remember being faced with spaghetti code 35 odd years ago - yes,
>> horrible.
>> > But what do we mean by ''spaghetti code'' ? I remember code where every
>> 3rd
>> > statement was some form of GOTO - yuck!
>> >
>> > One very desirable feature of code is that it be clear, ie: lucid, able
>> to be
>> > understood by others. Too many GOTO statements and it is hard.
>> >
>> > However: a few GOTOs can make things clearer. Think of a function that
>> can fail
>> > in several different places (eg data validation, ...). But it is
>> reading a file
>> > which needs to be closed before the function returns. I have seen code
>> where
>> > some $IsError variable is tested in many places to see if things should
>> be done.
>> > That is just as bad as lots of GOTO -- often when having to write
>> something like
>> > that I will have a GOTO (in several places) to the bottom of the
>> function that
>> > closes the file and returns failure.
>> >
>> > That is much clearer than extra variables.
>> >
>> > If I survey my code I find that I use one GOTO in about 4,000 lines of
>> code -
>> > that I do not find excessive.
>> >
>> > There are, however, people who consider any GOTO as communion with the
>> devil.
>> > IMHO: not so - if used sparingly.
>>
>> Just for another data point, the FAA does not allow gotos in any code
>> that goes into an airplane.
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
> Can I have the source for this so I can read the rationale? I'm curious
> which language implementation it's referencing (C, Ada, etc.) and what
> restrictions the language places on the construct. Again, the PHP version
> of the construct is beneficially quite restrictive. For instance, some
> people don't like giving programmers access to pointers just because you
> can get into so much trouble with them, but I wonder if they'd be concerned
> about Go's pointers, which don't allow pointer arithmetic, limiting one are
> of potential trouble:
>
> http://golang.org/doc/go_for_cpp_programmers.html#Conceptual_Differences
>
> Interesting.
The source is my own personal experience working for an avionics
company and working with the FAA to get our code certified under the
DO-178B standard. I never saw anything that said 'no GOTOs' but that's
what I was told. I was also told no C++ was allowed nor was any
recursion. This was important to me, as we had purchased some code
that was all that (C++, with recursion and GOTOs) and I was given the
task of rewriting it in C and removing the gotos and the recursion.
--- End Message ---
--- Begin Message ---
On Mon, Feb 6, 2012 at 12:09 PM, Larry Martell
<la...@software-horizons.com>wrote:
>
> The source is my own personal experience working for an avionics
> company and working with the FAA to get our code certified under the
> DO-178B standard. I never saw anything that said 'no GOTOs' but that's
> what I was told. I was also told no C++ was allowed nor was any
> recursion. This was important to me, as we had purchased some code
> that was all that (C++, with recursion and GOTOs) and I was given the
> task of rewriting it in C and removing the gotos and the recursion.
>
Now that was probably a lot of work! Interesting that C++ was not allowed.
Thanks for the background information,
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
--- End Message ---
--- Begin Message ---
On Mon, Feb 6, 2012 at 11:58 AM, Tim Streater <t...@clothears.org.uk> wrote:
> On 06 Feb 2012 at 09:48, Adam Richardson <simples...@gmail.com> wrote:
>
> > On Mon, Feb 6, 2012 at 4:25 AM, Adam Richardson <simples...@gmail.com
> >wrote:
> >
> >> On Mon, Feb 6, 2012 at 4:07 AM, Tim Streater <t...@clothears.org.uk>
> wrote:
>
> >> I disagree that the nested function is a straw-man. I (just as the other
> >> authors I'd linked to describing the "arrow" pattern of code) have seen
> >> plenty of examples of similar code.
>
> I guess what I meant was, that I'd never have written it that way in the
> first place, so as an example it felt contrived. Amateurs or people with no
> training (in particular physicists at CERN 40 years ago) should be kept
> well clear of the goto. I'd probably write your function like this:
>
> function val_nested ($name = null, $value = null, $is_mutable = false)
> {
>
> static $values = array();
> static $mutables = array();
>
> if ($name===null) return $values;
>
> if ($value===null) return isset($values[$name]) ? $values[$name] :
> null;
>
> if (isset($values[$name]))
> {
>
> if (!$val_is_mutable = in_array($name, $mutables)) // Set
> existing value
> {
> $msg = 'The value "' . $name . '" is immutable and has
> already been set to ' . $values[$name] . '.';
> throw new Exception ($msg);
> }
>
> return $values[$name] = $value;
>
> }
>
> if ($is_mutable) $mutables[] = $name; // Set new
> value
> $values[$name] = $value;
>
> return $value;
>
> }
>
>
> I always add blank lines for clarity. Remove those and the above is 30%
> shorter than yours - as far as I could tell, none of the else clauses was
> required.
>
> My approach is:
>
> 1) deal with the trivial and error cases first
>
> 2) deal with the real work next
>
> --
> Cheers -- Tim
>
Thanks for providing your example, Tim. Bailing early through guard clauses
towards the top of the function body is a nice approach (I used it in my
second example, but I also used conditional grouping and factoring out
functions so I could display all three techniques listed in the post.)
I might try performing some experiments using the different versions of the
code and test for things like:
- Time it takes to add some additional piece of functionality to the code.
- Number of bugs in the revision.
- Time it takes for one to write a new function using only one of the
possible techniques (deep nesting, guard clauses, pulling out functions,
goto, etc.)
- Providing function input and testing accuracy of predicted output
Thanks for the time you've taken to provide your PHP coding preference in
this situation.
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
--- End Message ---
--- Begin Message ---
"Adam Richardson" <simples...@gmail.com> wrote in message
news:cac6cjqz5wku8c9ruqgc4rqg5cq35a-lfs1rryos3wtfys6r...@mail.gmail.com...
> On Mon, Feb 6, 2012 at 10:05 AM, Robert Cummings
> <rob...@interjinn.com>wrote:
>
>> On 12-02-06 04:07 AM, Tim Streater wrote:
>>
>>> On 06 Feb 2012 at 07:47, Adam
>>> Richardson<simpleshot@gmail.**com<simples...@gmail.com>>
>>> wrote:
>>>
>>> While not purely focused on PHP, I toss this out to the group because I
>>>> believe there are some novel, interesting points regarding the
>>>> potential
>>>> benefits of using the goto construct as implemented in PHP:
>>>>
>>>> http://adamjonrichardson.com/**2012/02/06/long-live-the-goto-**
>>>> statement/<http://adamjonrichardson.com/2012/02/06/long-live-the-goto-statement/>
>>>>
>>>
>>> Your val_nested() function looks like a straw-man to me. I've not used a
>>> goto since I stopped writing in FORTRAN in 1978, and not missed it [1].
>>> Neither do I ever have deeply nested if-then-else - these are a good
>>> source
>>> of bugs. I suppose the rest of your article might have been dealing with
>>> simplifying val_nested() but TBH I wasn't interested enough to find out.
>>>
>>> [1] Not quite true - a Pascal compiler I once had to use in 1983 lacked
>>> a
>>> return statement, so I had to fake it by putting a 999: label at the end
>>> of
>>> the function and goto-ing to that.
>>>
>>
>> Goto has it's uses, demonizing it due to the poor implementation and
>> misuse of it's same-named historical counterparts is an exercise in
>> closed-mindedness. Goto can really shine in parsers and various other
>> scenarios. While the example shown may be contrived it doesn't miss the
>> point. Since goto cannot jump out of the function nor jump into the
>> function it is well constrained to provide readability while eliminating
>> complexity. Additionally, it is quite likely that it is more optimal. A
>> single jump target versus one or more state variables to control nested
>> conditionals or loops results in faster execution (also important for
>> parsers).
>>
>> I've had a strong opinion on goto for a very long time. I was one of the
>> proponents who argued on internals for its inclusion several years ago. I
>> stand by its utility and refer the reader to the fact that many open
>> source
>> projects, especially ones that use some kind of parser, have goto hidden
>> within their implementation. You can find it in the C code for the PHP,
>> MySQL, and Apache to name a few easily recognizable projects.
>>
>> Cheers,
>> Rob.
>
>
> All excellent points, Robert.
>
> Tim mentioned that my example was a straw-man, and you mentioned it was
> contrived. Actually, it's a refactoring of a real function in my web
> framework that I've committed to trunk and going to use for a while (it's
> functionally inspired, and having the ability to store and retrieve
> immutable values is quite handy in this situation.)
>
> I like experimenting with different approaches (my background is in
> cognitive psychology), and there's certainly research to show that deeply
> nested ifs are problematic, cognitively speaking. Then, there are the
> other
> techniques mentioned in the blog post to deal with them (guard clauses,
> pulling out functions, grouping conditions), but they have they're issues,
> too, in terms of processing (they can hurt proximity of related concepts,
> forcing programmers to work against the mental model they've built up of a
> problem, etc.) There are going to be issues with the goto approach I took
> to refactoring the function, too, but I'm keenly interested in playing
> around with it a while and letting the evidence accrue over time. I've
> read
> many, many sources that seem to reject ANY approach using GOTO even
> without
> properly evaluating its use within a language like PHP that offers some
> beneficial restrictions.
>
> Thanks for the insights (and I'm glad you pushed for the construct :)
>
> Adam
>
> --
> Nephtali: A simple, flexible, fast, and security-focused PHP framework
> http://nephtaliproject.com
>
The use of goto was acceptable in the early days of computer programming.
It was a major part of it in fact. I believe that the trend to remove them
from usage was because of that very thing. The early programs naturally had
to go thru improvements & maintenance but a new generation of programmers
came along and that was when the problem with GoTos was realized. It was
difficult if not impossible to follow a process completely through so that
one could implement a change easily and in the end people unfamiliar with
the entire program were forced to put code into multiple spots to ensure
that the change they were trying to implement got hit in all the correct
circumstances.
Gotos allow for too much flexibility and open up diverging paths in the flow
of the process. Sure - it works for the original developer, but code must
be seen as not the work of one author but as a product that can later be
modified/improved/corrected by future authors. Sure - you can say that the
life of a specific program/module may not be that long in today's fast-paced
changing technologies, but the same argument will be had no matter what is
in use on any given day.
--- End Message ---
--- Begin Message ---
"Robert Cummings" <rob...@interjinn.com> wrote in message
news:4f30086a.6080...@interjinn.com...
1) deal with the trivial and error cases first
>
> Some say you should never return early from a function... I too think that
> early returns can improve the readability of a function--
> especially if they are short snippets of logic that clearly indicate the
> reason for an early exit (usually edge case constraints).
>
> :)
>
> Cheers,
> Rob.
> --
I agree. Using multiple returns is merely a goto. Maintenance of that
function must then take into account those "multiple paths" in that function
as the changes are added. Modifying the original function to remove the
returns so that *all* flows will encounter the 'new' code can cause problems
if today's author misses something in the logical path of the process(es).
--- End Message ---
--- Begin Message ---
On Mon, Feb 6, 2012 at 10:13 AM, Adam Richardson <simples...@gmail.com> wrote:
> On Mon, Feb 6, 2012 at 12:09 PM, Larry Martell
> <la...@software-horizons.com>wrote:
>
>>
>> The source is my own personal experience working for an avionics
>> company and working with the FAA to get our code certified under the
>> DO-178B standard. I never saw anything that said 'no GOTOs' but that's
>> what I was told. I was also told no C++ was allowed nor was any
>> recursion. This was important to me, as we had purchased some code
>> that was all that (C++, with recursion and GOTOs) and I was given the
>> task of rewriting it in C and removing the gotos and the recursion.
>>
>
> Now that was probably a lot of work! Interesting that C++ was not allowed.
>
> Thanks for the background information,
I was a lot of work, but I was a contractor getting paid by the hour ;-);
I just pulled out my notes from that job - it took me 59 hours to do
the conversion and remove the gotos and recursion, and another 67
hours for testing, verification, integration, documentation, and
certification.
--- End Message ---
