incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: Asset / i18n resource management improvements
Date Tue, 12 Jun 2012 22:50:25 GMT

On 6/12/12 3:39 PM, "Om" <> wrote:

> 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.
Both implementations are inefficient given how often you tend to look up
strings.  You are initializing all of these properties when it isn't even
clear they will be used.  I still think you are better off just embedding a
delimited text file and parsing it on the fly.  But it still needs proving.

> 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.
The use of dynamic property access is not causing poor runtime performance,
it is this particular implementation (wrapping an object in a class).  For
casual occasional access, dynamic access is more efficient than a lot of
class and object initialization code that never gets a chance to pay off.
> But it wont generate compiler errors/warnings for missing keys or
> wrong key usage.
It doesn't today, and won't tomorrow.  But my point is that some future IDE
could by learning how to read the properties files in the project.

Alex Harui
Flex SDK Team
Adobe Systems, Inc.

View raw message