Tool to externalize strings

A

Anonymous user

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
 
O

Oliver Wong

Anonymous user said:
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.

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
 
A

Anonymous user

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.



thx for your comments.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top