Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75951
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <53CFA55D.2030105@lsces.co.uk>
Date: Wed, 23 Jul 2014 13:06:53 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAESVnVq5P26Yi=w1yF3ETBEPe+PwJdEAuJ3-8Yw5vsQBy7ofDw@mail.gmail.com>
In-Reply-To: <CAESVnVq5P26Yi=w1yF3ETBEPe+PwJdEAuJ3-8Yw5vsQBy7ofDw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP Language Specification
From: lester@lsces.co.uk (Lester Caine)

On 22/07/14 20:50, Sara Golemon wrote:
> http://dl.hhvm.com/resources/PHPSpec-SneakPeak.pdf

I know this is a peak at the new documentation, but it flagged up
something when I was scanning through.

switch Statement ...

I have always put the 'default:' as the last item in the list since it's
what is left after processing all the other options and one may or may
not have fallen out.

So I went to http://php.net/docs.php to check out there, and putting
'switch' in the search box it's not then obvious that one HAS to hit
enter to get the function switch? It would be nice if 'switch' appeared
in the drop down list?

Anyway, having then found the right page, some of the subtleties
documented in the spec are not covered in the manual. In fact I don't
think that what is described in the spec is actually what happens in
code? This is perhaps the reason that a formal spec is long overdue. The
manual says the statements are actioned in order, and certainly that is
what I expect so I can add bits in the flow through, but does the switch
statement know that a value is not listed as a case prior to scanning
the code?

Also included in the spec is the 'alternative syntax' which should
perhaps be tagged differently going forward? I know both styles of
working can be randomly mixed, but some sort of 'grouping' for style
variations would enhance the spec's usability.

Switching back to managing the spec content, and integrating it with
other material, as an example, a link on the
php.net/manual/en/control-structures.switch.php to the relevant section
in the spec is perhaps just to obvious, but is another example of where
a central repository for content just makes common sense ... We have
asked in the past the the manual pages are updated when RFC's are
created, so pull all of that together in the one process? I'm just not
sure 'git' is the right container for doing it? Moving the content of
the dokuwiki into git would at least allow that to be used and mirrored
as other materiel.

-- 
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