From:             
Operating system: Linux
PHP version:      5.3.2
Package:          Unknown/Other Function
Bug Type:         Feature/Change Request
Bug description:You're doing the wrong thing with string accessors

Description:
------------
I should have made more fuss about this earlier, but here it is now.



I think you are taking exactly the wrong approach to addressing single

characters in strings.  I am of the very strong opinion that the direct

addressing of characters in strings have an obvious syntactic difference
from

the addressing of array elements.  This means you should keep {} and
deprecate

[] for addressing characters in strings.



PHP is not C!!  In C, strings are arrays, so [] is the preferred C operator
to

address single bytes (or character codes) in a string.  In PHP, strings are
a

primitive type; they are not arrays.  The notation $foo{0} makes it plain
that

$foo is a string, not an array and that you are accessing a byte, not an
array

element.  Making this obvious through the syntax is more important than
you

might think.



Imagine $bar to be a 3x3 array of strings.  In this case, what are you to

assume when you see in the middle of a script, far away from the assignment
to

$bar, when you read

   $baz = $bar[$a][$b][$c];



If you have instead

   $baz = $bar[$a][$b]{$c};

you know you're not doing ordinary array addressing.



These issues become important for the people who have to maintain the code.


Consider two more ways confusion can arise because strings are not arrays.



If $abc is a string,

   $d = $abc[2];

works but

   $abc[2] = array('boo');

fails.  The elements of a string "array" do not work like true array
elements.



Indices to strings must be integers; unlike arrays, strings do not allow

associative indices.  This fails:

   $abc['key'] = 'def';



I believe that indicating single-byte access via [] is such a bad idea that
if

you're dead set on removing {}, I would prefer to deprecate that kind of
access

altogether in favor of substr() and friends.


-- 
Edit bug report at http://bugs.php.net/bug.php?id=52381&edit=1
-- 
Try a snapshot (PHP 5.2):            
http://bugs.php.net/fix.php?id=52381&r=trysnapshot52
Try a snapshot (PHP 5.3):            
http://bugs.php.net/fix.php?id=52381&r=trysnapshot53
Try a snapshot (trunk):              
http://bugs.php.net/fix.php?id=52381&r=trysnapshottrunk
Fixed in SVN:                        
http://bugs.php.net/fix.php?id=52381&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=52381&r=needdocs
Fixed in release:                    
http://bugs.php.net/fix.php?id=52381&r=alreadyfixed
Need backtrace:                      
http://bugs.php.net/fix.php?id=52381&r=needtrace
Need Reproduce Script:               
http://bugs.php.net/fix.php?id=52381&r=needscript
Try newer version:                   
http://bugs.php.net/fix.php?id=52381&r=oldversion
Not developer issue:                 
http://bugs.php.net/fix.php?id=52381&r=support
Expected behavior:                   
http://bugs.php.net/fix.php?id=52381&r=notwrong
Not enough info:                     
http://bugs.php.net/fix.php?id=52381&r=notenoughinfo
Submitted twice:                     
http://bugs.php.net/fix.php?id=52381&r=submittedtwice
register_globals:                    
http://bugs.php.net/fix.php?id=52381&r=globals
PHP 4 support discontinued:          http://bugs.php.net/fix.php?id=52381&r=php4
Daylight Savings:                    http://bugs.php.net/fix.php?id=52381&r=dst
IIS Stability:                       
http://bugs.php.net/fix.php?id=52381&r=isapi
Install GNU Sed:                     
http://bugs.php.net/fix.php?id=52381&r=gnused
Floating point limitations:          
http://bugs.php.net/fix.php?id=52381&r=float
No Zend Extensions:                  
http://bugs.php.net/fix.php?id=52381&r=nozend
MySQL Configuration Error:           
http://bugs.php.net/fix.php?id=52381&r=mysqlcfg

Reply via email to