[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