On 2010-05-01, at 8:36 AM, Travis Griggs wrote:

> On Apr 30, 2010, at 11:32 AM, Hernán Morales Durand wrote:
> 
>> Ok, and still not convinced at all the advantages of that approach
>> over normal message sending. What's the real limitation of common
>> objects for implementing a "discovering mechanism"? It's simply
>> another subsystem, it could be easier or harder than others, but I'm
>> sure you don't *need* to use already weird syntax to implement it.
>> All the tags stuff smells like people wanting to experiment "cool
>> things" with DSL's but is using us as testers.
> 
> 
> I didn't implement them originally, I just live with them (happily enough) and make use of them. I'm curious what you would do differently? How would you make it so can send a message to Behavior X, and fetch me all of the methods that belong to a given service? Would you just use method categories? Or maybe just embed literal arrays in the CompiledMethod frame, and scan for those? Or pattern match something from method comments?


I wrestled with this issue when designing OmniBrowser, so perhaps exploring it with a concrete example might be illuminating.

The problem I had was this: I wanted OmniBrowser to be modular, so that you could load only parts of it. If you had a constrained environment, for example, you could load just a basic lightweight browser, but other folks could use the full RB functionality just by loading some additional packages. Or if you had some browser extensions that were only useful in certain situations you could publish it as a optional package that didn't require modifying the core browser code.

The solution I hit on was a system of commands. Commands are a sort of UI-independent abstraction used to build menus and button bars. A command provides a service (like, say, removing a method), and knows what sort of context is required for that service to make sense (eg, a method is selected). It also knows how to describe its self to the user ('remove method') without knowing what sort of UI (Morphic, MVC, Gtk) or widget (menu or button) is being used to present it. 

When the browser needs to build a menu, it looks at the available commands, figures out which ones are applicable to the current state of the UI, and builds the appropriate menu. This makes it easy to extend the browser - just create a class that implements a simple protocol, and add a method that answers that class to the browser class you want to extend. It's more object-oriented than the ever-expanding pragma DSL that Travis was describing.

So far, so good, but there's still the problem of discovery! How do you gather up the list of commands that should be available for a given browser? I used reflection in OB: when the browser first opens, it searches its own dictionary for unary selectors that begin with 'cmd', and sends its self all those messages. It hangs on to the classes that get answered, and uses them to generate commands as needed. Nice and simple, but it's a bit of a hack. 

Now that Pragmas (MethodTags) are well supported in Squeak and Pharo, I've been thinking of using them instead. At least it would be a "standard" hack, one that' used in other parts of the system. The question is how much to put in the tags? It could be as simple as <command>, and then scan for tagged methods instead of selectors with a prefix. Or it could be more complex, something that describes how to create commands. 

Colin