Things is not so easy as it looks at first sight.
The problem here, i think, that compiling process is overburden with
different other functionality,
which not related to compiling per se, but related to recording the
method source, and
error handling.

The compilation should be broken on stages:
 - creating a compiled method instance (Compiler responsibility)
 - installing method into class (Behavior responsibility)
 - announcing the change (system-change framework responsibility)

the facilities which should log the change should live in separate
layer, and listen for system change announcement,
as well as any other tools.

Because, if you look at currently the number of selectors which start
from 'compile:'

#compile:
#compile:class:
#compile:classified:
#compile:classified:notifying:
#compile:classified:notifying:trailer:ifFail:
#compile:classified:withStamp:notifying:
#compile:classified:withStamp:notifying:logSource:
#compile:classified:withStamp:notifying:logSource:inClass:
#compile:in:classified:notifying:ifFail:
#compile:in:notifying:ifFail:
#compile:in:requestor:
#compile:notifying:
#compile:selector:

its really terrifying...


2009/11/3 Niko Schwarz <[email protected]>:
> Well, I can rename the compile: method and post to PharoInbox, if
> anyone is interested.
>
> Niko
>
> On Tue, Nov 3, 2009 at 5:19 PM, Gary Chambers <[email protected]> 
> wrote:
>> +1 too. Fewer side-effects and/or more side-effect free refactoring is
>> better.
>>
>> Regards, Gary
>>
>> ----- Original Message -----
>> From: "Igor Stasenko" <[email protected]>
>> To: <[email protected]>
>> Sent: Tuesday, November 03, 2009 3:56 PM
>> Subject: Re: [Pharo-project] Compiler compile:
>>
>>
>>> +1 Niko.
>>> There should be an easy interface for compiling the source code
>>> without installing the result into system.
>>> And of course, compiler should answer an instance of compiled method
>>>
>>> 2009/11/3 Niko Schwarz <[email protected]>:
>>>> Hi list,
>>>>
>>>> consider this code:
>>>>
>>>> c := Compiler compile: 'meth "bla" ^ 2'.
>>>>
>>> Try using
>>>
>>> c:= Compiler new
>>>     compiledMethodFor: ...
>>>
>>>
>>> The class-side #compile:... method , is method which serves for
>>> directly compiling & installing the method into receiver.
>>> In the above case - into Compiler class, but you can also do that for
>>> any other class:
>>>
>>> MyClass compile: ....
>>>
>>>> Here, c will be set to the symbol #meth. And Compiler will be added a
>>>> new method "meth".
>>>>
>>>> This is of course counter-intuitive, but it's kind of wired into the
>>>> system. Behavior>compile: does certainly more than compile. It
>>>> compiles the code and adds it to itself, then returns the methodName
>>>> as a symbol. Without mirrors, it's hard to do it right, though.
>>>>
>>>> Also, there's an easy method to add a method to a class, but no easy
>>>> method to get a CompiledMethod object. I don't want to strongly
>>>> advocate for my change, I just want to offer it. Here's what I did in
>>>> my system:
>>>>
>>>> I changed Compiler>compile: to do the following:
>>>> class side:
>>>>
>>>> compile: aString onClass: aClass
>>>> ^ self new compiledMethodFor: aString onClass: aClass
>>>>
>>>> instance side:
>>>>
>>>> compiledMethodFor: textOrStream onClass: aClass
>>>>
>>>> | methodNode method |
>>>> class := aClass.
>>>> self from: textOrStream class: class context: nil notifying: nil.
>>>> methodNode := self translate: sourceStream noPattern: false ifFail:
>>>> [^self error: 'Compilation failed'].
>>>> method := methodNode generate: #(0 0 0 0).
>>>> self interactive ifTrue:
>>>> [method := method copyWithTempsFromMethodNode: methodNode].
>>>> ^method
>>>>
>>>> This has its own problem, like: compile: suddenly has different
>>>> semantics on Compiler than anywhere else. Best might be renaming
>>>> Behavior>compile: to something more intuitive. Like
>>>> #compileFromAndAdd:.
>>>>
>>>> Cheers,
>>>>
>>>> Niko
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [email protected]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [email protected]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to