3 ms·
What have you got against symbols exactly? I don't know enough about the reasons why they are implemented to argue this strongly, but I know that they are immu
by yebyen 8y ago
What have you got against symbols exactly?
I don't know enough about the reasons why they are implemented to argue this strongly, but I know that they are immutable and that they are one step closer to the language in the sense that, constructions which you may not use in an unquoted symbol, are also not allowed to be used in a Ruby method name.
That seems like a handy data structure to have around next to a string (and nobody's stopping you from using a string if you wanted a string and not a symbol, ...or are they?)
- samatman 8y agoIn Lua, symbols are just strings, all strings are immutable via internment, and the symbol rules constrain the parser, not the runtime. So obj.field is shorthand for obj["field"], you can have obj["="] if you want, it means obj.= but that is of course a syntax error. I find this approach more comfortable and easy to reason about than a separate Symbol class.
- yebyen 8y agoThanks! Pretty sure you can get progressive versions of this type of behavior (where obj["field"] is equivalent to obj[:field] or obj.field) by using Ruby's HashWithIndifferentAccess and/or OpenStruct classes, but those are both obviously more obscure than something which is a built-in default language feature.
- samatman 8y agoIt's one of several decisions that make Lua's type system easy to reason about. Another one is that environments themselves are simply tables, the global is _G, and environments can be set and retrieved on functions. Kinda like mutable Mars ^_^