[etoys-dev] Translation support
Bert Freudenberg
bert at freudenbergs.de
Mon May 3 09:36:24 EDT 2010
On 03.05.2010, at 12:58, Hilaire Fernandes
<hilaire.fernandes at edu.ge.ch> wrote:
>
>
> 2010/5/2 Bert Freudenberg <bert at freudenbergs.de>
> On 02.05.2010, at 00:16, Bert Freudenberg wrote:
> > There is a slight problem with extension methods (methods defined
> in *categories), #translated currently would look for those in the
> wrong package:
> >
> > We need to make #translated deal with this. I can think of a
> simple but inefficient way to do it - maybe it wouldn't hurt that
> much?
>
> I wonder if method properties could come to the rescue here. We
> could simply store the translation domain as property of the
> compiled method itself. We have about 1500 methods that send
> #translated, so that seems not to be bad at all space-wise, and
> should perform very well.
>
>
> What are method properties?
> I don' t understand how it will work?
>
> Hilaire
I'm just talking about an implementation detail. You do not have to
worry about it, just use #translated in your code as usual.
"Method properties" are additional state you can attach to a compiled
method. Similar to pragmas, but invisible. They are not created by
tags in the source code while compiling, but are attached later.
I'm just proposing to use them to cache the translation domain for a
method. Figuring this out properly at runtime is expensive (the code
needs to work its way from the compiled method to the package it
belongs to).
With this I think we could even get rid of the class registration? The
translation domain would just be the package name of the method that
sent #translated. How does that sound?
- Bert -
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://lists.squeakland.org/pipermail/etoys-dev/attachments/20100503/39ffa6b8/attachment.html
More information about the etoys-dev
mailing list