Condensed Sources vs. Squeak Maintainence
Klaus D. Witzel
klaus.witzel at cobss.com
Mon Jul 24 19:45:25 UTC 2006
On Mon, 24 Jul 2006 19:44:01 +0200, Marcus Denker wrote:
> On 24.07.2006, at 18:21, Klaus D. Witzel wrote:
>>> By the selector of a Method is not "meta"!
>> I'm sorry it is "meta" by tradition. Otherwise it would have been
>> stored in the method (literals) since the 80's of the previous
>> century. And if you cannot agree with that view:
>> only the VM knows about the relationship between the selector used
>> for method lookup and the found and executed method. This *is* what
>> meta is about, that's what I think.
> If the model that we want to have is just "execution", then this is
> correct. This is what we have now: A model describing classes/
> methods, where the description of the
> classes is both for the machine and the programmer, but for methods
> we only model execution. What I would like to see (now that machines
> have become so
> much more powerful) is to move this model up one level and make it's
> main goal to be a model of the program for engineering, while keeping
> this model executionable.
I'm in sync.
> This is why a method should know it's class (this is what a developer
> thinks about a method) and it's name... the whole mode of the system
> should be on an abstraction
> level of that kind of model that you would design for a re-
> engineering or visualisation tool...
But by using methodClass (to which I fully agree), every method knows it
class, which knows its method dictionary, which knows the corresponding
selector (all a matter of implementation). No need for MethodProperties
And yes (and to make it clear): every method nowadays has methodClass
(except perhaps those circumscribed in a comment, similiar to 'bad case'
in the other thread). Since any two ~= classes cannot be the same type, so
their methods. So methodClass *must* be checked for by CompiledMethod>>#=
... (which, BTW, doesn't check the selector, in any version I've seen so
> e.g. for execution, a class needs no name, just like a method needs
> no name. You could have nameless "CompiledClasses". But the objects
> encoding classes we do
> have a slot for the name...
Good point. This is equivalent to (Smalltalk keyAtValue: aSlot), same as
for (aMethodDictionary keyAtValue: aCompiledMethod), a matter of
performance at the time of invention (CompiledMethod instanceCount > (...
allObjectsdo: ... isBehavior ...) size, a subject for lengthy discussions
in modern times ;-)
> Because they have not only the
> interpreter as the client, but the developer tools (and the
> developer), too. Because it makes no sense to
> destinguish between the two: The higher level model with name is
> perfectly executable, too.
Sure, the higher level is "just" about *organization*, *reuse* and other
elaborate concepts, a typical reason for introducing execution unrelated
meta data (similiar to ClassDescription).
> It makes the tools much simpler: In 3.9, methods know their class
> without having to search the whole system. As soon as that was done,
> I started to refactor a little... it
> turns out that this information makes the design simpler: e.g no need
> to call "decompileClass: aClass selector: selector" on the
> compiledMethod... just call
> decompile on the method, no need to funnel the extra information to
> all the places where they are needed.
Yes, when I saw that it was quite a surprise how easy things can be ;-)
Good reason for marking these oldies with #deprecated:.
> For the tools, it feels much
> more natural if the methods
> know more than nothing... as then the class/method structure will be
> your meta model that you can use directly.
O.K. but the level we are talking about here is equivalent to [at least]
Behavior>>#allCallsOn: why the heck should Behavior know anything about
calls to symbols in CompiledMethods? It delegates.
So can CompiledMethod (delegate) when asked the queries you mentioned. It
doesn't need to store anything else than Blue Book's methodClass for
obtaining these answers (by delegation).
I second implementing all possible queries and oops related to
CompiledMethod in CompiledMethod. Perhaps as a separator for a redesign:
oops which are unrelated to CompiledMethod>>#= (unrelated to type-,
function-, computational-equivalency "PCE") do not belong to
CompiledMethod. A few examples for the unrelated: #categoryOfElement:,
#tempNames, source-origin-server, source-origin-path, source-origin-uri,
source-origin-version, ..., source-origin-name (selector) they shouted
when the baby was born ;-)
More information about the Squeak-dev