Re: switch(String)?
Daniel Bonniot <[email protected]> Sun, 04 Jul 2004 12:05:53 +0200
| Newsgroups | gmane.comp.lang.nice.general |
|---|---|
| Message-ID | <[email protected]> |
Hi Adam,
> String s = ...
> switch(s) {
> case "bar":
> case "baz":
[...]
> The need for this sort of stuff comes up quite often in parsers for
> both languages and TCP-based, pre-XML-era protocols, and is often a
> performance bottleneck if implemented as a gigantic
> if..else..else..else block with String.equals().
Agreed, I see the need for such a feature.
There is a question about what syntax it should use. At the moment there
is no switch statement at all in the language. Instead, you can define
methods by case on primitive types, strings, or enums. For instance, you
can define:
Token parse(String);
parse("bar") = ...; // you could use the { ... } syntax too, as usual
parse("baz") = ...;
Then in your initial code, you would call the 'parse' method.
So something clear is that implementing this existing feature with the
technique you mention should lead to significant speed improvements
(it's using equals at the moment), and that would be very welcome.
An orthogonoal question is whether this syntax is sufficient, or
something closer to switch is also needed. There are pros (familiarity,
conciseness, use of local variables in the case actions) and cons
(encourage to write long piece of code instead of naming an action
implemented separately, awkwardness of the default fall-through
behaviour of switch, added complexity to the language). So I would be
interested to hear opinions about this.
One compromise could be to allow local methods (defined inside another
method) to be defined by case. That would allow the actions to make use
of local variables, while staying more in the spirit of the language.
> More to the point: I'm interested in using Nice in general, and would
> be even more interested if it meant I could have one less preprocessor
> in my build sequence. I'd like to add this feature to Nice; is this
> something that (if written cleanly and properly) would be likely to
> make it back into the upstream source tree?
Definitely. The design of new features can be discussed here on
nice-info (hence the forward). For questions and help about the
implementation, you can use nice-devel (and so you should subscribe).
Don't hesitate to ask questions, it should save you time.
> Further generalizations might allow any 'final' field to be used as a
> case arm; in the case of Object derivitaves, appropriate code (in the
> constructor or static block) could be emitted to build a hashtable
> which would then be used to decide the branching path.
At the moment, you can already dispatch a method on a constant. For
instance:
let String bar = "bar";
boolean foo(String s) = false; // default case
foo(bar) = true;
void main(String[] args)
{
assert foo("bar");
}
Does that help?
Cheers,
Daniel
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com