From: Matthew Kerwin Date: 2013-02-08T06:11:08+09:00 Subject: [ruby-core:52005] Re: [ruby-trunk - Feature #7792] Make symbols and strings the same thing --f46d042ef591bff84d04d528cbee Content-Type: text/plain; charset=ISO-8859-1 On 7 February 2013 23:09, Rodrigo Rosenfeld Rosas wrote: > Enums have two goals in such languages. Improving performance and > reducing memory footprint is one of them. The other one is to help the > compiler to find errors at compile time by restricting the input type in > some functions/methods and variables. I don't really understand how this > is relevant to this discussion. No, no no no. Enums exist because they are identifiers. They are symbolic representations of a concept that either does not necessarily otherwise exist in the code, or does not have to be fully instantiated in order to discuss it. That is exactly what Symbols are. > They don't spend their time thinking about whether they should be using > symbols or strings. They don't WANT to worry about it! Your overarching goal is to coddle developers who write code without understanding either the language, or the concepts behind their own code. There is a massive philosophical disjunct here between you and I, and I think it will never be overcome. > I agree it is unlike to happen. What about another syntax: {{a: 1}} => > {'a' => 1}? Maybe it would worth trying to ask for some syntax change > like this one. We could even add interpolation to it: > {{"value #{computed}": 1}}. You'd probably be more likely to succeed with a new %string-style notation, like %h{a:1, b:2}. Although then again, possibly not. --f46d042ef591bff84d04d528cbee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 7 February 2013 23:09, Rodrigo Rosenfeld Rosas wro= te:
> Enums have two goals in such languages. Improving performance a= nd
> reducing memory footprint is one of them. The other one is to he= lp the
> compiler to find errors at compile time by restricting the input type = in
> some functions/methods and variables. I don't really underst= and how this
> is relevant to this discussion.

No, no no no. E= nums exist because they are identifiers.=A0 They are symbolic representatio= ns of a concept that either does not necessarily otherwise exist in the cod= e, or does not have to be fully instantiated in order to discuss it.=A0 Tha= t is exactly what Symbols are.


> They don't spend their time thinking about whether they sh= ould be using
> symbols or strings. They don't WANT to worry abou= t it!

Your overarching goal is to coddle developers who write code w= ithout understanding either the language, or the concepts behind their own = code.=A0 There is a massive philosophical disjunct here between you and I, = and I think it will never be overcome.


> I agree it is unlike to happen. What about another syntax: {{a= : 1}} =3D>
> {'a' =3D> 1}? Maybe it would worth trying = to ask for some syntax change
> like this one. We could even add inte= rpolation to it:
> {{"value #{computed}": 1}}.

You'd probably be mor= e likely to succeed with a new %string-style notation, like %h{a:1, b:2}.= =A0 Although then again, possibly not.

--f46d042ef591bff84d04d528cbee--