Tool to externalize strings

Thread view:

Anonymous user - 27 Jan 2006 12:12 GMT

Hello,

i've watched a little bit the existing tools to help externalize
strings but none of them is really great. Does anybody know if the
described tool below exists?
- in IDE:
* warns about badness of complex string constructs like "at position
" + pos + "."
- juste before compilation (on the fly):
* replace all strings literals ("*") by xxx.yyy.Resources.get(id)
* create a default properties file with { id="*" }
- in a separate tool
* GUI like:
| lang1 | lang2 |
----------------------
| str1 | str2 |

pros:
- you don't need to assign an id for each string (like in Eclipse tool)
- you don't see the ugly call to the resources in you IDE

cons:
- it surely slow down compilation, but it worth it

Does that exists? If no have you any idea why? If you think it's not a
good tool, plz explain why.

TIA

Reply to this Message

Oliver Wong - 27 Jan 2006 22:42 GMT

> Hello,
>
[quoted text clipped - 22 lines]
> Does that exists? If no have you any idea why? If you think it's not a
> good tool, plz explain why.

The first downside I could think of off the top of my head is that you
don't want to externalize ALL Strings, especially when doing stuff with
Reflection, or specifying hardcoded filenames, URLs, etc.

The second one that comes to mind is that is detecting the "badness of
complex string constructs" could be difficult, for example, if a string is
constructed through a deeply recursive calls. It sort of implies the machine
understanding the intent of the programmer.

The third one is that when two strings are semantically identical, they
should have the same id, but the tool would probably not be able to
determine when two strings are semantically identical (note that just
because two strings are identical in one language doesn't mean that they are
semantically identical in all languages).

But for some common "small" applications, it does seem like it would
save time over Eclipse's method.

Rather than "Just before compilation, on the fly", how about a GUI tool
that goes through all your Java files and asks you which ones you want to
externalize, and which ones you want to keep as is?

- Oliver

Reply to this Message

Anonymous user - 30 Jan 2006 09:51 GMT

> The first downside I could think of off the top of my head is that you
> don't want to externalize ALL Strings, especially when doing stuff with
> Reflection, or specifying hardcoded filenames, URLs, etc.

Yeah but it could be configured, at the first run, you externalize
everything. To get the strings. And you "unselect" some of them in a
GUI tool for next run.

> The second one that comes to mind is that is detecting the "badness of
> complex string constructs" could be difficult, for example, if a string is
> constructed through a deeply recursive calls. It sort of implies the machine
> understanding the intent of the programmer.

no handling a complex case. A computer is dumb and will always be. The
aim is just to handle 90% of dumb case it can understand. The aim is to
avoid losing time on dumb things.

It would requires a way to take over control of the tool for complex
cases.

> The third one is that when two strings are semantically identical, they
> should have the same id, but the tool would probably not be able to
> determine when two strings are semantically identical (note that just
> because two strings are identical in one language doesn't mean that they are
> semantically identical in all languages).

it seems like the exception not the rule to me, but i might be wrong.
One again you could forbig the coalescing (good word?) of all the
similar strings by looking at their filename/linenumber for example.

> But for some common "small" applications, it does seem like it would
> save time over Eclipse's method.

thx :)

> Rather than "Just before compilation, on the fly", how about a GUI tool
> that goes through all your Java files and asks you which ones you want to
> externalize, and which ones you want to keep as is?

It would be great! But more complicated to do i think.

> - Oliver

thx for your comments.

Reply to this Message

Tool to externalize strings

Free Magazines