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