[AlexMuir]

I have a lot of fondness for Yii as it introduced me to MVC and moved me from a designer into a developer. When I went on to learn Ruby and Rails everything seemed to click together and I recognised quite a lot of what Yii had taken from Rails.

That said, I get the sweats when I have to wade into an old Yii-powered app that I wrote. Entirely faults of PHP (lack of symbols, array(...) declarations, semicolon-itis) and my lack of experience back then (no testing, fat controllers). I do miss the simplicity of deploying a Yii app, and its speed compared to Rails. The creator, Qiang, is a PHP whizz.

[coldtea]

>Entirely faults of PHP (lack of symbols, array(...) declarations, semicolon-itis)

Sorry, but those are entirely trivial syntactic issues, and not very interesting at that either...

[bigtunacan]

Symbols are not a syntactic issue. They are an optimization issue. They do not have the creation overhead of objects and they exist across the application in memory without the lookup overhead of a constant (PHP's closest cousin to a symbol).

Lisp, Erlang, and Prolog (sure some other languages I've missed) have direct equivalents to Ruby symbols; they are sometimes referred to as symbols other times as atoms.

Saying they are a trivial syntactic issue just means you don't understand what symbols are.

[lmz]

It's a bit silly to worry about the overhead of strings over symbols when the PHP environment itself is not persistent across requests.

[bigtunacan]

That seems to be missing the whole point of symbols/atoms. They are uniquely identified with an O(1) lookup time and persist in memory after the initial creation. Symbols persist across multiple requests; this is a big part of why they are so beneficial.

[girvo]

I'm not disagreeing with you, but

> Symbols persist across multiple requests; this is a big part of why they are so beneficial.

That is still not really useful, PHP throws the entire execution context away after the request has finished. There is no sharing nor anything to persist unless you're doing so with an external data-store.

[windowsworkstoo]

Wait, isn't that just if it's used/configured as a CGI? If you use it as a webserver module (Apache/IIS/Lightspeed), the execution environment can persist in a similar way to an app domain, right?

[bigtunacan]

Girvo, I was not saying that within the context of how PHP operates symbols/atoms would be beneficial.

The parent stated, "Sorry, but those are entirely trivial syntactic issues, and not very interesting at that either..."

My point was that symbols/atoms are much more than just a syntactic difference and that they are in fact quite interesting. Chicago Boss, an Erlang framework, takes these ideas to an extreme to push the limits of shared immutable memory on a web server.

http://www.chicagoboss.org/about.htm

I'm not a big fan of the way he trashes pretty much every alternative at the beginning of his description; there are many web frameworks built on many different languages that the market has proved out are sufficiently scalable.

It is however an interesting and different approach that I think we can both agree goes far beyond "trivial syntactic issues".

[pestaa]

It adds up. One request may produce millions of such strings. Ruby and especially RoR without cheap symbol lookups would be as fast as a dead fish.

[coldtea]

You're not supposed to have "millions of symbols" in Ruby (or LISP for that matter) either.

I mean, you technically could, but it's not what they are used for.

[nikic]

Ruby only needs symbols because it made the questionable choice of using mutable strings with by-object semantics. PHP does not have this problem. It will automatically intern literal strings, thus giving you the performance and memory usage benefits of symbols, but without the crutch of requiring a special syntax for them.

[Daishiman]

I think that special symbol syntax is nice, since it has additional semantic meaning in the form of "this data type here is used to represent a flag, not a piece of text".

Granted, Ruby's use of symbols is not as pretty as other languages...