There are a lot of things that are worse in the Squeak image. I'm not saying this is good and should not improve, but if those selectors are spread over suitable classes (acting as entry points) with some convenience methods among the list, it's not necessarily that much worse than Dolphin's organization of it.
That's a lot of "ifs" though. +1 (and then some) on the idea of making it easy to create a compiled method w/o installing it, and for making it clear (probably by where the methods are placed the selector/arguments) which versions do nothing but compile, and which versions install the method if successful. Clear comments won't hurt either. Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Igor Stasenko Sent: Tuesday, November 03, 2009 4:24 PM To: [email protected] Subject: Re: [Pharo-project] Compiler compile: 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
