There are more clean ups coming soon, when i'll figure out the right order
to not break the update stream:

The light ones:
-------------------

Compiler>>notify:(at:) is (are) not required
An Encoder can notify its requestor (a Parser!) of a bytecode limit or
incorrect variable usage.
A Parser can notify itself of a syntax error.
But no one is ever going to notify a Compiler.
A Compiler is just a facade, it does not much work by itself...

A Compiler does not need to know about category.
A Compiler compiles, it does not classify.
The only usage of CompilationCue category right know is to display it in
the SyntaxError window!
Better remove this feature, that's a bunch of simplifications in long
parameter chains.
We also remove the inst. var. from CompilationCue, SyntaxError,
SyntaxErrorNotification.

I realized this when writing CompilationCue comments.
Class comments are really usefull, not only for the clients, they also help
the producer to introspect its own design.

Generally, we pass too many parameters to a Compiler.
OK, we need some sort of source code, and (or?) the TextEditor if
interactive (requestor).
Then the compilation context should simply be:
- either a class for compiling a method, (for resolving inst/class/shared
variable names)
- or a receiver for evaluating some code (the class is then receiver class,
no need to pass anything)
- or a context for evaluating code in a debugger (the receiver is then the
context receiver, and the class is the receiver class)
Then we may pass an environment if not the default (for resolving global
vars).
All these are in the CompilationCue.
And finally, a failBlock is most often provided.

Having messages for union of these cases does not sound the right thing to
me.
Looking at usage, we see 1/3 of nil passed as parameters, which stinks.
I already shrinked the nil passing a bit, and removed a few methods, but I
feel I did not go far enough.

The big ones:
-----------------

A possibility is to expose the CompilationCue (CompilationContext?).
The instance creation messages could hold the minimal requirements:
- source:class:
- source:receiver:
- source:context:
Same with sourceEditor: if it ever replace source, otherwise this could
just be an instance side setter.
Then we could either add messages with the optional environment:
parameters, or just let it be an instance setter too...
I'm not at all convinced about exposing the helper class, but maybe
something like this:
.    (Compiler forEvaluating: aString in: receiver) parseIfFail: failBlock
.    (Compiler forEvaluating: aString in: receiver) compileIfFail: failBlock
.    (Compiler forEvaluating: aString inContext: aContext) evaluateIfFail:
failBlock
.    (Compiler forCompiling: aString inClass: aClass) formatIfFail:
failBlock
This would have the merit to avoid the funny duplication of class-side and
instance-side API.

We could have specialized messages for interactive requestor (TextEditor or
PragraphEditor for nostalghia):
.    (Compiler forEvaluatingInEditor: anEditor) ...

It may sound more natural to write:
.    (Compiler forEvaluatingIn: receiver) parse: sourceString ifFail:
failBlock
But the sourceString and/or Editor has to be in the CompilationCue right
now, and a single Compiler instance cannot easily compile two different
strings as the error handling is written right now (we may try to change
this too eventually).

Since Compiler is only a facade, we could have two facades instead,
(Evaluator forSource: aString receiver: anObject) and (Compiler forSource:
aString class: aClass).
After all, we have compilerClass and evaluatorClass. Though it sounds a bit
revolutionary right now given current Compiler usage in a trunk image (way
too many refs)...

Maybe I'll give a try to some of these ideas in the inbox...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130920/5f283711/attachment.htm