Hi dominic
I suggest to read the smalltalk companion design pattern this is excellent and you have all kinds of discussion on using or not reflecting features.
Some drafts are available on my books pages
Stef On Wednesday, May 21, 2003, at 12:27 AM, Dominic Fox wrote:
On Tuesday 20 May 2003 1:18 pm, Noury Bouraqadi wrote:
Hi Dominic,
You can play with MetaclassTalk (http://csl.ensm-douai.fr/MetaclassTalk). It provides a running MOP that enhances Squeak reflective facilities. So, you can have a meta-object that controls how instance variables reads and write are done for an arbitrary set of objects, control message sends/reception, method look-up and evaluation...
Noury
One to get back to when I've more of a handle on things, I think, but it sounds intriguing.
I've nicked my copy of Design Patterns back from work, and notice that the Chain of Responsibility pattern mentions Smalltalk's #doesNotUnderstand as a way of intercepting messages that can't be handled at the current link in the chain and need to be forwarded on.
What do I want this kind of thing for? Well, I use a dynamic proxy every time I connect to a web service with a VB client: the MS SOAP Toolkit supplies a component that can be configured at run-time by passing it a WSDL document, and then works more or less like a DCOM proxy only with SOAP messages passing along the wire. A more banal example is the DHTML support in Microsoft's HTML library: in order to simulate Javascript syntax, e.g. document.all.NameOfAnElement.click(), the collection objects dynamically resolve unknown method calls into indexed retrieval, e.g. document.all.items("NameOfAnElement").click(). This is the kind of trick you can pull in COM/C++ by customising the IDispatch code, but can't do at all in straight VB.
More generally, if you're working in an environment where resources and services are dynamically discovered and accessed, as they sometimes are when you consume web pages or services, then it's helpful to be able to use the native syntax of the language to work with generic components that mould their interfaces to suit that environment. An alternative would be to subclass the generic components and add the resource- or service- specific methods by hand (or via some nifty code generation), but sometimes it's more comfortable to have the component sort these things out for you on demand.
I'm going to shut up now and go and do some actual Smalltalk coding - let you know next time I get stuck...
thanks, Dominic