php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #34543 Improving usability by redefining use of semicolon as statement separator
Submitted: 2005-09-18 19:48 UTC Modified: 2005-09-18 19:58 UTC
From: douglas dot s dot green at gmail dot com Assigned:
Status: Not a bug Package: Feature/Change Request
PHP Version: * OS: *
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: douglas dot s dot green at gmail dot com
New email:
PHP Version: OS:

 

 [2005-09-18 19:48 UTC] douglas dot s dot green at gmail dot com
Description:
------------
The semicolon as a statement separator has usability issues in general (not just for PHP, for all languages that use this method).  First of all, it is 99% redundant.  In almost all the code I have ever seen, there is a one-statement-per-line norm.  The rare exception is when multiple statements are put on one line (almost no one ever does this and it is discouraged) and when a single statement is continued to multiple lines (this happens rather more often).

So if you have a 10,000 statement program (excluding blocks or whatever), you must remember to place 10,000 semicolons.  Lack of any one of those 10,000 semicolons can cause the program not to run because of a syntax error.  All this just so that in 1% of cases, a statement can be put on multiple lines without the use of a continuation operator.  So you are spending 10,000 to save 100.

It seems to me that an alternate syntax could be developed that dispenses with semicolons as separator, and uses a continuation operator instead to signal the presence of multiple lines, something like >>.

Reproduce code:
---------------
// This example does not show a BUG, it merely demonstrates a proposed FEATURE using code from this site
class Exception  {
   protected $message = 'Unknown exception'  // exception message
   protected $code = 0                        // user defined exception code
   protected $file                            // source filename of exception
   protected $line                            // source line of exception

   function __construct($message = null,  >>
      $code = 0);

   final function getMessage()                // message of exception
   final function getCode()                  // code of exception
   final function getFile()                  // source filename
   final function getLine()                  // source line
   final function getTrace()                  // an array of the backtrace()
   final function getTraceAsString()          // formated string of trace

   /* Overrideable */
   function __toString()                      // formated string for display
}

Expected result:
----------------
Beginning PHP programmers get happy because they do not have to look at obscure error messages that really mean a semicolon is missing.

Actual result:
--------------
Beginning programmers waste 30 minutes staring at their code trying to figure out where the semicolons should go.  Repeat times infinity.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-09-18 19:58 UTC] helly@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

If you look at c/c++ you'll find out why c-like language keep with the ;. For one there are things that need the ; to distinguish where an expression is ending (and there is no other way) and second these languages allow multi line statments so the ; is the best way to increase readability and bring clearification to both programmers and compilers.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 09:01:26 2024 UTC