B
Brian Candler
I'm posting this here for some advice on whether this is a bug, or
intentional behaviour.
ruby 1.9.2-preview1 is quite capable of distinguishing Unicode
upper-case characters. However this doesn't seem to be used when
deciding whether an identifier is a constant or a local variable.
I am not sure from the source code whether this is intentional or not.
In parse.c it uses rb_enc_isupper which understands encodings:
else if (rb_enc_isupper(m[0], enc)) {
id = ID_CONST;
}
else {
id = ID_LOCAL;
This is in rb_intern3. And yet it is called from rb_intern2 which says:
ID
rb_intern2(const char *name, long len)
{
return rb_intern3(name, len, rb_usascii_encoding());
}
thereby ignoring the source encoding and saying always use ASCII rules.
Can someone confirm if this is the behaviour which is intended?
intentional behaviour.
ruby 1.9.2-preview1 is quite capable of distinguishing Unicode
upper-case characters. However this doesn't seem to be used when
deciding whether an identifier is a constant or a local variable.
=> [:ÜBER]SCHÖN = 1 # constant => 1
ÃœBER = 2 # local variable! => 2
self.class.constants.grep(/SCH|BER/) => [:SCHÖN]
local_variables.grep(/SCH|BER/)
I am not sure from the source code whether this is intentional or not.
In parse.c it uses rb_enc_isupper which understands encodings:
else if (rb_enc_isupper(m[0], enc)) {
id = ID_CONST;
}
else {
id = ID_LOCAL;
This is in rb_intern3. And yet it is called from rb_intern2 which says:
ID
rb_intern2(const char *name, long len)
{
return rb_intern3(name, len, rb_usascii_encoding());
}
thereby ignoring the source encoding and saying always use ASCII rules.
Can someone confirm if this is the behaviour which is intended?