If symbols could use the sign bit or otherwise distinguish from typical integer
keys one would have some hope of meaningful debugging output. I don't think it
makes sense to mix integer keys and symbol keys but being able to differentiate
them for debugging purposes would be great. However since php arrays are sparse
anyway is there much of a win from integer keys in the first place?
Sent from my iPhone
On Jan 5, 2013, at 6:28 AM, "Ivan Enderlin @ Hoa"
<ivan.ender...@hoa-project.net> wrote:
> Hi :-),
>
> Nice proposal but I have few questions and remarks.
>
> My first question is how to delete symbols? I don't know if it is useful or
> not. We should discuss about that. Is `unset(:foo)` enough? How are they
> handled by the GC?
>
> Another question is: where are we able to use symbols? Is it allowed to write
> `const FOO = :bar` for example? Or in a default argument value: `public
> function f ( $x = :foo ) { … }`?
>
> What kind of (arithmetical) operations are allowed on symbols?
>
> You proposed to represent symbols as integers. Could it create conflicts? For
> example: `$foo = [0 => 'bar', :baz => 'qux']`. What happens if `:baz` is set
> to 0?
>
> Finally, if my memory is good, a few months ago, some patches were updating
> “constant strings” performances by representing them as “buffers”/“constants”
> internally, no? Maybe I'm wrong, but it could be a middle-way solution if it
> is not yet implemented (especially since we have strings dereferencing,
> implementation could be ease).
>
> My two cents :-).
> Best regards.
>
>
>
>
> On 05/01/13 15:07, Nikita Nefedov wrote:
>> 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?
>> You can read about it here:
>> http://www.randomhacks.net/articles/2007/01/20/13-ways-of-looking-at-a-ruby-symbol
>>
>> It can be implemented in PHP as a HashTable where key would be strings and
>> values would be unique identifiers (just incrementing long, can be tracked
>> with nNextFreeElement).
>>
>> How it would work in userland?
>>
>> If it would be proposal, I would divide it on two different (competitive)
>> proposals:
>>
>> First, we could implement it so symbol expression would return an associated
>> integer.
>> (note that symbols are most often used as hash keys in ruby so my examples
>> are relying on it)
>> Example:
>> $foo = array();
>> $foo[:bar] = "qwerty";
>>
>> var_dump($foo);
>> // array(1) {
>> // [0] =>
>> // string(6) "qwerty"
>> //}
>>
>> var_dump(:bar); // int(0)
>>
>> var_dump(:some_new_symbol); // int(1)
>>
>> This is the easiest way, and I can implement it. But, it would be hard to
>> debug.
>>
>> The second way - we can implement it as a new variable type, and the main
>> thing is that arrays will be able to take variables of symbol type as keys,
>> I know it sounds scary but it's not so hard actually.
>> I will drop the part about new variable type, the main thing is how
>> HashTables could work with symbols as keys.
>> We could change the type of nKeyLength (in Bucket) to signed integer (now
>> it's unsigned, I don't think we will miss something from that) and use it as
>> a flag: if it's -1 (less than zero) - then we know the symbol was used as a
>> key, there will be filled bucket.h member with a symbol identifier.
>> That way the above code will evaluate so:
>> $foo = array();
>> $foo[:bar] = "qwerty";
>>
>> var_dump($foo);
>> // array(1) {
>> // [:bar] =>
>> // string(6) "qwerty"
>> //}
>>
>> var_dump(:bar); // symbol(:bar)
>>
>> var_dump(:some_new_symbol); // symbol(:some_new_symbol)
>>
>> To make it clear, when retrieving an element by symbol from array, these
>> steps will be needed:
>> 1. Get symbol identifier (ulong)
>> 2. Get elements from array where bucket.h equals to this identifier
>> 3. Iterate over those elements and find the one that has nKeyLength == -1
>> (actually we will iterate over pNext/pLast elements)
>>
>>
>> What symbols can give:
>> 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:
>> $builder
>> ->add('title', 'text', array(
>> 'label' => 'Album title'
>> ))
>> ->add('title_alias', 'text', array(
>> 'label' => 'Album alias',
>> 'required' => false,
>> 'property_path' => 'properties.titleAlias'
>> ))
>> ->add('comment', 'text', array(
>> 'label' => 'Comment',
>> 'required' => false,
>> 'property_path' => 'properties.comment'
>> ))
>> ->add('labels', 'text', array(
>> 'label' => 'Musical labels',
>> 'required' => false,
>> 'property_path' => 'properties.labels'
>> ))
>> ->add('language', 'text', array(
>> 'required' => false,
>> 'property_path' => 'properties.language'
>> ))
>> It could be improved this way:
>> $builder
>> ->add('title', :text, array(
>> :label => 'Album title'
>> ))
>> ->add('title_alias', :text, array(
>> :label => 'Album alias',
>> :required => false,
>> :property_path => 'properties.titleAlias'
>> ))
>> ->add('comment', :text, array(
>> :label => 'Comment',
>> :required => false,
>> :property_path => 'properties.comment'
>> ))
>> ->add('labels', :text, array(
>> :label => 'Musical labels',
>> :required => false,
>> :property_path => 'properties.labels'
>> ))
>> ->add('language', :text, array(
>> :required => false,
>> :property_path => 'properties.language'
>> ))
>> 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.
>> 3. Memory leaks. Symbols can't be just garbage collected as, for example
>> zvals, it's not possible. But we can do it for every request, so I don't
>> think it would be problem.
>> 4. Autocompletion from IDEs.
>>
>> PS I don't want to call it "proposal", despite the fact that this is
>> actually a proposal, I'm just not sure it can go as a proposal.
>>
>
> --
> Ivan Enderlin
> Developer of Hoa
> http://hoa.42/ or http://hoa-project.net/
>
> PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
> http://disc.univ-fcomte.fr/ and http://www.inria.fr/
>
> Member of HTML and WebApps Working Group of W3C
> http://w3.org/
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
