Condensed Sources vs. Squeak Maintainence
denker at iam.unibe.ch
Mon Jul 24 10:11:31 UTC 2006
On 24.07.2006, at 11:54, Klaus D. Witzel wrote:
> Hi Marcus,
> since every other project (package) depends on the integrity of the
> source code mechanism, I hereby volunteer to get a new source code
> subsystem (incl. code history) done during this summer. We have no
> time to wait for a new (reliable, scalable, available) source code
> mechanism, so I intend to make resources available for this project.
Good! But we should not wait with 3.9 for this.
> Here's a draft for a new source code subsystem:
> 0] (digit for Wolfgang ;-) there are at least three preferences:
> 1] use the traditional subsystem as is
> 2] use Dan Ingalls Source Compression as suggested earlier
> 3] use a service based (network based) mechanism
> I've studied the recent additions which where made to
> CompiledMethod w.r.t. MethodProperties, this has to be cleaned up
> before anything else can be done.
> No, I'm not a friend of storing any MetaData *in* the meta data's
By the selector of a Method is not "meta"! Every method should have a
name, and if you want a method with another name, make a new method.
Even the very idea of
different names for the same method is not a good one, as the name is
hard-coded in the sourcecode, too. It's a direct, non-meta property
of the method object.
> I propose to put the MethodProperties into the MethodDictionary
> where they belong (same method can *and will* have different
> properties per class
Methods should be only installed in one class. yes... Traits, sigh...
the copying of Traits is evil... I think a better model for traits
would have been to share Bytecode,
not Methods. But then in Squeak these two concepts have been mangled
into one for space reasons, which was a bad idea in general. (Or: It
was a bad idea not
to harvest Tims fix in 1998...).
> = one MethodProperties in each class' method dictionary). As a
> consequence, today's MethodProperties would all be garbage
> collected (except for the few pragmas), because all they store is
> the selector. And CompiledMethod>>#selector is resolved by
> #methodClass and #keyAtValue: so #who can disappear as is intended.
> After that, the *new* source code information can be put into the
> new MethodProperties, which allows an easy migration because the
> old source code pointer won't be touched until after migration.
You can do that even in the current structure. The sourcePointer is
now per Method, too.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3938 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20060724/2838a9db/smime.bin
More information about the Squeak-dev