>
> To me, the most important thing to get right is the run-time
> implementation.
> Once we nail that, someone will figure out how to get you something like
> code-hinting.
>
Just to be clear, the benefit is not only code-hinting, it is also compile
time error checking. If a key does not appear in autocomplete and the user
goes ahead and tries to use it, there will a warning/error generated
depending on how we want to implement it. It will also be useful during
refactoring of code.
Fundamentally, IMO, a string-only resource system is a simple lookup table
> of a string key to a longer string. Then for organizational purposes folks
> tend to group those keys into bundles.
>
> What we do today is bake classes for these bundles. Then we install these
> classes into a manager at startup time. And we do that for error strings
> you may never see, and Alert labels you hopefully will not see before the
> first screen appears. And the classes are actually quite big compared to
> simply embedding a string table in the SWF (or loading the string table at
> runtime). Also, it isn't clear you need a class. You might be able to
> use
> simple dynamic objects instead.
>
>
Yes, we do bake classes for these bundles but still, the implementation is
such that it is useless for autocompletion and compile time checks. From
the docs[1], here is the generated class for a resource bundle in the
current implementation:
public class RegistrationForm_properties extends ResourceBundle {
override protected function getContent():Object {
var properties:Object = {};
properties["registration_button"] = "Registration";
properties["submit_button"] = "Submit Form";
properties["personname"] = "Name";
.
.
.
return properties;
}
}
The new way would be something like (Dirk, please correct me if I am off here) :
public class RegistrationForm_properties {
public static var registration_button:String = "Registration";
public static var submit_button:String = "Submit Form";
public static var personname:String = "Name";
.
.
.
}
}
Runtime overhead wise, the second implementation will be a bit lesser
because we
dont use the generic object or any do any dynamic key lookup.
And the classes are actually quite big compared to
> simply embedding a string table in the SWF (or loading the string table at
> runtime). Also, it isn't clear you need a class. You might be able to
> use
> simple dynamic objects instead.
>
> And if we decide that classes have too much overhead and simply use dynamic
> objects, what would then happen to code hinting? There wouldn't be any
> classes to hint. How would you find spelling errors in the keys? I'd hate
> to see us drag down runtime performance just so you can get code-hinting.
I dont think we should use dynamic classes at all. Which is kind of
what happens today. It causes poor runtime
performance and it does not help in compile time.
I think some IDE will someday be smart enough to look at the string tables
> and help you get your keys right.
>
But it wont generate compiler errors/warnings for missing keys or
wrong key usage.
[1]
http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7f2d.html#WS2db454920e96a9e51e63e3d11c0bf69084-7f34
