Compiler compile:
Locked
 
|
Hi list,
consider this code: c := Compiler compile: 'meth "bla" ^ 2'. 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
+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 <[hidden email]>: > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
+1 too. Fewer side-effects and/or more side-effect free refactoring is
better. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <[hidden email]> To: <[hidden email]> 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 <[hidden email]>: >> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 <[hidden email]> wrote: > +1 too. Fewer side-effects and/or more side-effect free refactoring is > better. > > Regards, Gary > > ----- Original Message ----- > From: "Igor Stasenko" <[hidden email]> > To: <[hidden email]> > 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 <[hidden email]>: >>> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
> Well, I can rename the compile: method and post to PharoInbox, if
> anyone is interested. Also I agree that it is confusing, but there are tons of projects that depend on this function. #compile: and #compile:classified: are about the only two compiler related methods that are available cross platform. If you rename them you will break any code that compiles something, including the Refactoring Browser, SmaCC, OmniBrowser, Seaside (for the file libraries), etc. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by niko.schwarz
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 <[hidden email]>: > 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 <[hidden email]> wrote: >> +1 too. Fewer side-effects and/or more side-effect free refactoring is >> better. >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Igor Stasenko" <[hidden email]> >> To: <[hidden email]> >> 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 <[hidden email]>: >>>> 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 >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
2009/11/3 Lukas Renggli <[hidden email]>:
>> Well, I can rename the compile: method and post to PharoInbox, if >> anyone is interested. > > Also I agree that it is confusing, but there are tons of projects that > depend on this function. #compile: and #compile:classified: are about > the only two compiler related methods that are available cross > platform. If you rename them you will break any code that compiles > something, including the Refactoring Browser, SmaCC, OmniBrowser, > Seaside (for the file libraries), etc. > But inner API should be simplified. For instance, take a look at compiler invocation here: self compilerClass new compile: code in: self classified: category notifying: requestor ifFail: failBlock. i really don't understand, why compiler would be interested in a method's category? What is the purpose of passing this extra info to compiler? The main purpose of compiler is to produce the CompiledMethod instance, and compiler should not care about anything related to installation of the resulting method into class and its categorization. > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Igor Stasenko
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: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko Sent: Tuesday, November 03, 2009 4:24 PM To: [hidden email] 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 <[hidden email]>: > 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 <[hidden email]> wrote: >> +1 too. Fewer side-effects and/or more side-effect free refactoring >> +is >> better. >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Igor Stasenko" <[hidden email]> >> To: <[hidden email]> >> 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 <[hidden email]>: >>>> 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 >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
Every project needs to have sacred cows that may not be tipped :D.
Well, alright, in case that we can't agree on renaming, how about my original proposal, which left everything the way it was and only added the class-side compile:onClass: method to Compiler? Possibly sided by compile:onClass:ifFail: Cheers, Niko On Tue, Nov 3, 2009 at 10:23 PM, Lukas Renggli <[hidden email]> wrote: >> Well, I can rename the compile: method and post to PharoInbox, if >> anyone is interested. > > Also I agree that it is confusing, but there are tons of projects that > depend on this function. #compile: and #compile:classified: are about > the only two compiler related methods that are available cross > platform. If you rename them you will break any code that compiles > something, including the Refactoring Browser, SmaCC, OmniBrowser, > Seaside (for the file libraries), etc. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Igor Stasenko
I think that what we should get is
Compiler compile: 'text' with: aCompilingContext aCompilingContext should hold the information about where: in classified: failing noytfying .... Stef On Nov 3, 2009, at 10:32 PM, Igor Stasenko wrote: > 2009/11/3 Lukas Renggli <[hidden email]>: >>> Well, I can rename the compile: method and post to PharoInbox, if >>> anyone is interested. >> >> Also I agree that it is confusing, but there are tons of projects >> that >> depend on this function. #compile: and #compile:classified: are about >> the only two compiler related methods that are available cross >> platform. If you rename them you will break any code that compiles >> something, including the Refactoring Browser, SmaCC, OmniBrowser, >> Seaside (for the file libraries), etc. >> > You are right , of course. > > But inner API should be simplified. > For instance, take a look at compiler invocation here: > > self compilerClass new > compile: code > in: self > classified: category > notifying: requestor > ifFail: failBlock. > > i really don't understand, why compiler would be interested in a > method's category? > What is the purpose of passing this extra info to compiler? > The main purpose of compiler is to produce the CompiledMethod > instance, and compiler should not care > about anything related to installation of the resulting method into > class and its categorization. > > >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
What would be nice is to propose a nice interface (based on compiler
context to remove this argument plague) Then to slowly migrate to it using deprecation. Stef On Nov 3, 2009, at 10:23 PM, Lukas Renggli wrote: >> Well, I can rename the compile: method and post to PharoInbox, if >> anyone is interested. > > Also I agree that it is confusing, but there are tons of projects that > depend on this function. #compile: and #compile:classified: are about > the only two compiler related methods that are available cross > platform. If you rename them you will break any code that compiles > something, including the Refactoring Browser, SmaCC, OmniBrowser, > Seaside (for the file libraries), etc. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by niko.schwarz
Niko what would be cool is that you design a new interface
so that we can see how it feels and we integrate it. rename is for simple and fast stuff. Migrating is for used software. :) On Nov 4, 2009, at 10:20 AM, Niko Schwarz wrote: > Every project needs to have sacred cows that may not be tipped :D. > > Well, alright, in case that we can't agree on renaming, how about my > original proposal, which left everything the way it was and only added > the class-side compile:onClass: method to Compiler? Possibly sided by > compile:onClass:ifFail: > > Cheers, > > Niko > > On Tue, Nov 3, 2009 at 10:23 PM, Lukas Renggli <[hidden email]> > wrote: >>> Well, I can rename the compile: method and post to PharoInbox, if >>> anyone is interested. >> >> Also I agree that it is confusing, but there are tons of projects >> that >> depend on this function. #compile: and #compile:classified: are about >> the only two compiler related methods that are available cross >> platform. If you rename them you will break any code that compiles >> something, including the Refactoring Browser, SmaCC, OmniBrowser, >> Seaside (for the file libraries), etc. >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
2009/11/5 Stéphane Ducasse <[hidden email]>:
> I think that what we should get is > > > Compiler compile: 'text' with: aCompilingContext > > aCompilingContext should hold the information about > where: in > classified: > failing > noytfying > .... > Since i tried to get rid of that in Moebius, it wont hurt if i share my experience here :) Currently i end up with following public entry points for parsing and compiling: parse: sourceStream in: environment requestor: aRequestor parseDoIt: sourceStream in: environment requestor: aRequestor compile: aSourceStream in: env requestor: aRequestor compileDoIt: sourceStream in: environment requestor: aRequestor the requestor object in one who responsible for handling errors, warnings and notifications etc. and environment object is one who responsible for providing essentials, needed for a method where it will be installed & work, like resolving variables bindings etc. In most cases, the environment is some class. But there are things like doits in specific context during debugging, where environment object should 'see' not only the variables of receiver, but also temporary variables, declared in current context. These two objects + source code is enough to parse & produce a compiled method. I'm also had a variation, where Requestor was responsible for answering whether incoming source is doit or not (by having #noPattern method), but then i found that it would be more convenient to designate such intent more directly , and use different selector instead of requiring the requestor to implement additional protocol ('noPattern' method). > Stef > > On Nov 3, 2009, at 10:32 PM, Igor Stasenko wrote: > >> 2009/11/3 Lukas Renggli <[hidden email]>: >>>> Well, I can rename the compile: method and post to PharoInbox, if >>>> anyone is interested. >>> >>> Also I agree that it is confusing, but there are tons of projects >>> that >>> depend on this function. #compile: and #compile:classified: are about >>> the only two compiler related methods that are available cross >>> platform. If you rename them you will break any code that compiles >>> something, including the Refactoring Browser, SmaCC, OmniBrowser, >>> Seaside (for the file libraries), etc. >>> >> You are right , of course. >> >> But inner API should be simplified. >> For instance, take a look at compiler invocation here: >> >> self compilerClass new >> compile: code >> in: self >> classified: category >> notifying: requestor >> ifFail: failBlock. >> >> i really don't understand, why compiler would be interested in a >> method's category? >> What is the purpose of passing this extra info to compiler? >> The main purpose of compiler is to produce the CompiledMethod >> instance, and compiler should not care >> about anything related to installation of the resulting method into >> class and its categorization. >> >> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |