Add syntax for character code constants. #4415

Open
lrhn opened this Issue Aug 8, 2012 · 12 comments

Comments

Projects
None yet
6 participants
Member

lrhn commented Aug 8, 2012

The currently simplest way to get the character code of the character '9' is either "9".charCodeAt(0), which isn't even constant, or writing the number constant, e.g., 0x39. Or define a whole slew of constants as in the dart2js characters.dart library:<http://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/lib/compiler/implementation/util/characters.dart>

It would improve readability and usability a lot if there was a simple way to specify "the character code of the character _", like C and Java's '9', Ruby's ?9, Scheme's #\9 or SML's #"9".

I propose the SML syntax since it doesn't collide with any other Dart syntax, and it could allow arbitrary Dart single-character string literals, piggy-backing on known string syntax, so it's possible to write, e.g., #"\n" instead of 0x10.
It should only work as a literal, no #stringVar or multi-character strings, or other funky stuff.

I don't want a character type, just a way to create integer constants that is both readable, simple and compile-time constant.

Contributor

gbracha commented Aug 8, 2012

Given that these are defined once and for all in the library and you can in fact write $F and get a readable, simple, concise constant, I'm not sure why we want a construct (consuming a valuable token that might be used for some more important syntactic construct).


Added this to the Later milestone.
Added Accepted label.

Member

lrhn commented Aug 8, 2012

I have a library now that handles a certain subset of characters. If I need other characters, or if other users need character codes, they will need to create their own library. It doesn't handle non-alphanumeric characters as well (q.v. $UNDERSCORE vs. #"_").

I think it makes sense for the language to support this feature instead of leaving it to libraries that are, by nature, either incomplete or very large.

DartBot commented Sep 5, 2012

This comment was originally written by @simonpai


Just adding my 2 cents. Perhaps Dart can supply a library for char constants? In that case:

  1. User can optionally include them
  2. User can prefix the constants by importing with prefix, which avoids name collision

IMHO, this feature is like the String joining utility that Java misses. It doesn't really block anything if absent, but it will end up with everyone rebuilding the same wheel in every Dart project.

Contributor

efortuna commented Mar 19, 2013

We have this available in the dart:html library. http://api.dartlang.org/docs/bleeding_edge/dart_html/KeyCode.html

Can we make it available for both platforms instead?

Member

lrhn commented Mar 20, 2013

The key code library is a good example of creating just the thing you need for one purpose. It only has one A code. I can't see from the api whether that is a lower or upper case A, but a character code library in would need both - and not have a "windows key" entry.

In other words, I don't see the general applicability of the library.

Contributor

efortuna commented Mar 20, 2013

right. I guess I missed that when I read this bug the first time. Yes, for the KeyCode library, by design, we are providing constants for the numbers associated with a particular key on a keyboard, (so there is only one code for "a", lower and upper case because it is the same key on the keyboard) not the ascii (or other) char code for the letters.

DartBot commented Mar 20, 2013

This comment was originally written by greg...@gmail.com


@Emily - I mixed up the key handlers and ascii in my email. Sorry for the confusion.

One advantage of having literals, is working with unicode characters. The $F constant example above obviously only works for characters which are also valid Dart identifiers.

For example - without literals:

const int _A_MACRON = 256; //'Ā'.codeUnits.first;

switch(c) {
   case _A_MACRON: print(c); break;
}

With literals - you can just write:

switch(c) {
   case c'Ā': print(c); break;
}

DartBot commented Mar 20, 2013

This comment was originally written by greg...@gmail.com


Oops - I see that's a dup of LRN's comment above.

Member

lrhn commented Aug 23, 2013

Issue #2093 has been merged into this issue.

Member

lrhn commented Apr 22, 2014

Issue #18322 has been merged into this issue.

Contributor

kasperl commented Jul 10, 2014

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

Contributor

kasperl commented Aug 4, 2014

Removed Oldschool-Milestone-Later label.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment