Pseudostrings


R

Roedy Green

I had an idea for a grammatical construct I will call pseudostrings.

They behave just like Strings, except when referenced, they invoke
some user code to produce the String.

You could initialised arrays with them, mixed in with regular strings,
ditto put them in collections.

You might use them:

1. to provide translations to the current language.

2. to automatically look something up in a database.

3. to automatically get information from a website.

4. to customize an app that did not have provision for customising.
You feed it pseudostrings in place of Strings.

5. to get the value from a Property.

How close could you get with Java?
--
Roedy Green Canadian Mind Products
http://mindprod.com

We are almost certainly going to miss our [global warming] deadline.
We cannot get the 10 lost years back, and by the time a new global agreement to
replace the Kyoto accord is negotiated and put into effect, there will probably
not be enough time left to stop the warming short of the point where we must not
go. ~ Gwynne Dyer
 
Ad

Advertisements

M

Mark Space

Roedy said:
How close could you get with Java?

Depends. Your pseudo-strings aren't immutable, so they won't mix
directly with a String. And String is final, so you can't extend it to
make a mutable string anyway.

There is an interface, CharSequence, which can often be passed where
you'd normally use a String. You could make a new class that implements
CharSequece which would be useful many places instead of a String.
 
R

Robert Klemme

Depends. Your pseudo-strings aren't immutable, so they won't mix
directly with a String. And String is final, so you can't extend it to
make a mutable string anyway.

There is an interface, CharSequence, which can often be passed where
you'd normally use a String. You could make a new class that implements
CharSequece which would be useful many places instead of a String.

True, but the interface has toString() as well as accessors for
individual characters. How do you decide when a new string needs to be
created when invoking those character methods?

I find the whole idea quite odd, there are too many issues. Mark
mentioned the major ones: you cannot replace something immutable with
something mutable - especially since you do not know how it is used
inside the component that you pass it to.

If this is only for lazy initialization I'd say it's not worth the effort.

Regards

robert
 
Ad

Advertisements

B

blue indigo

You might use them:

1. to provide translations to the current language.

That is what ResourceBundle, MessageFormat, and ChoiceFormat are for. The
only thing they don't do that you seem to desire here is to provide for
lazy initialization when the String is first used. Instead you can just
avoid instantiating the String until code that isn't yours needs it.
2. to automatically look something up in a database.

3. to automatically get information from a website.

Both of these have the problem that the "String" substitute would
potentially be throwing unexpected types of exception. Again, it is better
to get the String lazily in your own code, and handle any exceptions there.
4. to customize an app that did not have provision for customising. You
feed it pseudostrings in place of Strings.

I'm not sure how this could work in practise. An app ordinarily gets
String objects internally, and the only way to change their contents would
be to hack the class file containing the string constants used. Your
"pseudostrings" wouldn't change this, as near as I can tell. On the other
hand, if the app gets many of its strings from PropertiesResourceBundle,
then customization becomes as simple as editing the .properties file that
comes with it and that contains these strings. Adding localizations is
similarly simple, if it uses PropertiesResourceBundle with MessageFormat
and ChoiceFormat to localize.

The upshot here is:
* If you want your apps to be customizable in this manner, use the
aforementioned APIs to localize it and obtain its string constants.
* If you want to customize someone else's app and they didn't do this,
you will need to hack its class file.

The closest you can get to "pseudostrings" would be to run an app using a
heavily modified runtime -- all the security disabled and String.class
replaced with a non-final version, or with your own implementation that
calls an abstract initialize method to lazily acquire its char array, then
call into existing code with your mutant String class/subclass.

Even then, it's library code that uses Strings rather than full
pre-existing applications you'd be using. And then you might as well just
feed them normal Strings, as late as possible, initialized as suggested
above. Clients don't then need to run the app in a special runtime or hack
rt.jar or whatever, and the danger of your app's installer not producing a
runnable installation or else borking all the other java apps on the
machine goes away.
5. to get the value from a Property.
PropertiesResourceBundle.

How close could you get with Java?

Absent rt.jar-hacking and friends, PropertiesResourceBundle with
MessageFormat and ChoiceFormat.
 

Top