[UI] Compiler messages

[Bill Schwab]

Colin,

Is the change set simply an example, or does it address something I
missed?  The exceptions would have to be resumable, right?  I am
starting to wonder whether exceptions or events are a good fit, as they
both have overhead (especially exceptions??) that might be a problem
when loading large change sets.  It might be interesting to see what
Dolphin 6 does for its code mentor.  I bought it, but never converted
from 5.1, so it is not readily available, but I can get to it.

There is still the question of whether we want to simply gag the
messages or write something that is a true fix to the mainstream
release.  Any ideas?

Bill





Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bschwab at anest.ufl.edu
Tel: (352) 846-1285
FAX: (352) 392-7029

>>> cputney at wiresong.ca 11/12/07 1:53 AM >>>

On 11-Nov-07, at 12:44 PM, tim Rowledge wrote:

>
> On 11-Nov-07, at 12:10 PM, Colin Putney wrote:
>>>
>>
>> I don't have any advice about that, but I would like to suggest  
>> this: please, please don't continue the tradition of having the  
>> parser interact with the user directly by opening menus and what  
>> not. This is a horrifying design that has given me much grief with  
>> OmniBrowser.
>
> I'd say this is one of those places where exceptions have a clear  
> and valuable role.
>
> When there is an unknown variable, instead of using something like
> varname isUnknown ifTrue:[(PopUpMenu query:'is this a temp or cancel  
> compile') ifTrue:[self addTempNamed: varname] ifFalse:[^self  
> buggered]]
>
> try something a bit more like
> varname isUnknown ifTrue:[CompilerUnknownVariableName informWith:  
> varname forCompiler: self]

Yeah, that's what I ended up doing.