[Pharo-project] Compiler compile:
siguctua at gmail.com
Thu Nov 5 16:57:11 EST 2009
2009/11/5 Stéphane Ducasse <stephane.ducasse at inria.fr>:
> I think that what we should get is
> Compiler compile: 'text' with: aCompilingContext
> aCompilingContext should hold the information about
> where: in
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
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).
> On Nov 3, 2009, at 10:32 PM, Igor Stasenko wrote:
>> 2009/11/3 Lukas Renggli <renggli at gmail.com>:
>>>> 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
>>> 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 Renggli
>>> Pharo-project mailing list
>>> Pharo-project at lists.gforge.inria.fr
>> Best regards,
>> Igor Stasenko AKA sig.
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
Igor Stasenko AKA sig.
More information about the Pharo-dev