michel.bany at gmail.com
Tue Jul 24 08:50:44 UTC 2007
On 24 Jul 2007, at 09:34 , Philippe Marschall wrote:
> Probably the VW version hasn't been updated. I prefer xxxCache because
> caching it's an ugly hack, this marks it as such and avoids shadowing
> problems with instance variables. VW doesn't need this ugly hack since
> it has bytearray literals. A wrote a transformation tool based on RB
> that would transform methods to use bytearray literals. This could be
> automatically done on exporting to VW but there was no interest in
> this so far.
The VW versions can generate the methods in three flavors.
- byte array literals
- packed strings
xxxCache generation is used when #compileUseNewCompiler is false.
The Squeak compatibility layer provides support for Squeak preferences.
This allows the port of the Squeak code that rely of these preferences.
Out of the box #compileUseNewCompiler is set to true by the Squeak
FYI, preference #showDeprecationWarnings is also supported by the
Squeak compatibility layer, although I do not remember what it is
Since #compileUseNewCompiler is set to false, xxxCache generation
is never used. That's why the VW method in charge of xxxCache has this
strange comment "should not come here".
byte array literals are used when #favorStorage answers false.
packed strings are used when #favorStorage answers true.
Out of the box, #favorStorage answers false.
The current VW port mechanism would accept whatever comes from Squeak,
whether it is using xxxCache or byte arrays. At the moment all
based on xxxCache. I have not yet seen byte arrays in use in Squeak.
To summarize the above: when new binary files are uploaded into file
their corresponding methods are generated using byte arrays. However
binary files that were ported from Squeak are based on xxxCache. This
is perfectly legal.
I think this should be simplified: we should get rid of xxxCache
in VW and rework the corresponding code in SeasidePlatformSupport.
Sooner or later.
More information about the Seaside