Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64568
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50E8ADF5.6070504@sugarcrm.com>
References: <op.wqfyt8u1c9evq2@nikita2206-debian>
	<50E8ADF5.6070504@sugarcrm.com>
Date: Sat, 5 Jan 2013 15:29:09 -0800
Message-ID: <CAKOpQSwK4O1AYvQb+droY59Ms+a-Q62HBfD=DYrXpJKDG3Pi6A@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Nikita Nefedov <inefedor@gmail.com>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=485b397dd3b5883b4704d292f696
Subject: Re: [PHP-DEV] Ruby's symbols
From: kris.craig@gmail.com (Kris Craig)

--485b397dd3b5883b4704d292f696
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Jan 5, 2013 at 2:49 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
> > I know I shouldn't write "Ruby" in the subject of a letter for
> > php-internals ML, but... Just wanted to ask, is anybody interested in
> this
> > feature in PHP?
>
> As I understand, :foo is basically an interned string "foo". But in PHP
> all constant strings are interned now, so the only thing we gain is
> comparison speed. Given that the strings we're talking about is under 10
> chars, performance gain from this would be negligible, and symbols
> aren't frequently directly compared anyway. So what exactly we're
> gaining that is not there in just constant string?
>
> > $foo = array();
> > $foo[:bar] = "qwerty";
> >
> > var_dump($foo);
> > // array(1) {
> > //  [0] =>
> > //  string(6) "qwerty"
> > //}
>
> Here's a problem. How we know that :bar is 0? What if we serialized $foo
> and later loaded it back - would :bar still be 0? Would :bar be 0 in all
> scripts forever - and if not, how would we know where $foo[:bar] is
> actually stored when we combine two scripts? I think it can not work
> this way since link between :bar and actual hash key should be stable.
>
> > I will drop the part about new variable type, the main thing is how
> > HashTables could work with symbols as keys.
>
> HashTable can accept only string or number as key. As we have seen
> before, making number from :bar is very hard to pull off properly. And
> if we use string "bar", why not just use string "bar"?
>
> > 1. More convenient way to use it almost everywhere as a replacement for
> > strings and sometimes for constants. There's a lot of code that uses
> > arrays as a parameter-stores. For example, here's how you usually define
> a
> > form in Symfony2:
>
> How it's more convenient? I don't see any difference.
>
> > 2. Memory usage reduction. AFAIK, there's a lot of cases like the above
> > and the use of symbols would affect on memory usage significantly.
>
> I don't see any memory usage reduction - you still have to store the
> string. Could you explain how memory usage is reduced?
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I'm still a total newb when it comes to Ruby, but as I understand it, a
symbol can be particularly helpful by maximizing code readability without
sacrificing efficiency.  As a PHP guy, I tend to think of a Ruby symbol as
a constant that doesn't need to be defined or set.  Its value is set
internally and is not relevant in userland except for the fact that it is
unique and unchanging.

For example, in current PHP, let's say I just bought a dog:

<?php

define( 'BROWN', 0x01 );
define( 'BLACK', 0x02 );
define( 'PURPLE', 0x03 );

switch ( $color )
{
case BROWN:
// Brown dog!
break;
case BLACK:
// Black dog!
break;
case PURPLE:
// Purple dog!?
break;
}

?>

Now, if we had symbols, I could get rid of the constants and just do this
instead:

<?php

switch ( $color )
{
case :brown:
// Brown dog!
break;
case :black:
// Black dog!
break;
case :purple:
// Purple dog!?
break;
}

?>

In both cases, we really don't care what the actual values of brown, black,
and purple are.  We just want it to be unique so we can reference each of
them in a visually friendly way with minimal performance impact.  That's
where I could see a valid use-case for Ruby-like symbols in PHP.

--Kris

--485b397dd3b5883b4704d292f696--