[squeak-dev] Re: [Question] How do I use the OmniBrowser?

David Röthlisberger squeak at webcitas.ch
Tue Sep 30 20:25:13 UTC 2008


> That's the price to pay for having an intrusive browser....
> Browser assumptions about the semantics of #break #halt or any other 
> messages cannot be more than speculation...
> ...Speculation that we all agreed on some conventions that certainly are 
> not part of Smalltalk.
> 
> Apart
> - adhering these conventions (but we should not take this decision for 
> the sole reason of conforming to a tool, why let a Browser be that 
> tyrannic?)

Certainly you don't have to adhere to these conventions, but then you 
might have to accept that the tool doesn't do what it is intended to do. 
  Every tool has some conventions it relies on, in particular code 
browsers. It's difficult, in particular in Smalltalk, to build a useful 
code browser that does not rely on any conventions...
You don't have to organize methods in protocols, but then you have to 
accept that you just get one category 'unclassified', rendering the 
whole method protocol column useless.
The same with #break: if you re-implement that method in your subclasses 
of Object, then you give this method (probably) a different meaning than 
Object did. A code browser typically goes for the default behavior in a 
Squeak image, it can't (and IMHO doesn't have to) assume that other 
applications shadow behavior of #break, #halt, whatever.
I really don't see anything intrusive or tyrannic here. In the end, all 
you get when you re-implement #break is a (possibly) wrong icon for a 
method invoking your #break implementation. Things could be worse...

> - let the browser inferring receiver type (after all, most usages are 
> probably self break, so that might be a hint),

Was also thinking about this first. But here you rely on even more 
unsure conventions...

> - or using a statically typed language (oh no!)

Better not. ;)

> the last alternative I see is to add yet another Preference...

Evil, evil. ;)

> ... or maybe make the tools more general? Like:

This would certainly be interesting to have.

> - let user peek some lint rules (eventually by package or class)
> - process these rules and mark all methods using a questionable
>   message/pattern
>   (using a Wrapper, like a QuestionableCompiledMethod,
>   or adding yet another CompiledMethod attribute).
> - let the browser lazily highlight such marked methods,
> - and in a greater effort let it explain which part of code is
>   questionable and why (require using more details....)
> - let the user provide hints for immunizing some known_to_be_ok methods
>   against pedantic warnings (using annotations or method attributes?)
>   Beware, such hint should survive code externalization...


Cheers,
David





More information about the Squeak-dev mailing list