notes-computer-programming-programmingLanguageDesign-programmingConstructs3

there's values and references. and, there's literals and variables. these are analogous entities, but the former two are types of values that can go into variables, whereas the latter two are types of syntactical entites that can go into code (values that can go into ASTs). also, when a variable is encountered in code, the default is to replace it with its value (to override this, u must "quote"), whereas when a reference is encountered in a variable, the default can be that (like in Python), or it can be to leave it as a reference (like in C). The Python method seems clearer b/c you don't have to deal with the distinction b/t vals and refs inside variables. meta project connection?

inversion of control: when the application is called as something like an "event handler" for a framework (rather than the "typical" situation, where the application is in charge of the flow of control)

dependency injection: in OOP: ok, so you have an object with a field that contains a reference to another object. sometimes the first object calls a method on the second object. ok, great, so the implementation of the two objects is decoupled. But at some point, you're going to have to instantiate the first object and the second object, and pass the first object a reference to the second one. this is a special case of inversion of control because the first object is getting called by someone else.

some ways to do this:

• constructor injection: the first object's constructor takes a ref to the second obj as a param. this is like partial function application functional languages.
• setter injection: the first object has a setter method that takes a ref to the second obj as a param. in functional languages, this is like having an "object state" struct with a field holding the ref to the second obj, and a function that takes a state struct, and a ref to the second obj, and returns a modified state struct
• interface injection: there are two interfaces, one defining a method called receiveXXX(XXX), and one defining a method called provideSelf(target). The first object implements the XXXWanted interface, where XXX specifies the type of component to be plugged in (there can be various different such methods in one object, one for each type of component). The second object implements the provideSelf method. The implementation of provideSelf takes one argument, which is the first object; it casts this to the interface type ReceiveXXX? (provideSelf itself takes a generic object as its arg, so it has to cast it), and then it calls the receiveXXX method on that argument, passing self (the second object) into the XXX argument of XXX. receiveXXX then modifies the first argument to hold the reference to the second object. Now, all that the container (framework) has to do, after all of the objects in the role of first objects have been registered as components, and all of the objects in the role of second objects have been registered as providers, is to call each of the provideSelf methods in each provider, passing in the appropriate receiver. I'm sure there is some reason, but I don't understand the advantage of the complexity of interface injection. However, I like the injection of a service locator way also (interface injection used to inject a reference to a service locator, avoiding globals in the service locator), as in the "Avalon" example, perhaps even better. I guess in Jasper you won't be able to call a setter that you can't see; since the distinction b/t classes and interfaces is somewhat abolished, and since interfaces can be defined automatically, mb interface injection will be the same as setter injection there?

service locator: an object that you can query to find other services

i guess a virtue of setter or interface injection is that the framework can swap out services at mid-runtime by calling the component again (if this is allowed..). similarly, a virtue of service locator is that the component can call the framework again later. Avalon's approach (interface injection of a service locator) gives both of these. otoh the service locator should also be provided in the constructor so there isn't two setup phases.

Fowler's article: http://www.martinfowler.com/articles/injection.html notes: in his PicoContainer? constructor injection example, in the configureContainer routine, you didn't have to explicitly register the link from MovieLister? to MovieFinder?; PicoContainer? must have introspected and saw that MovieLister?'s constructor takes a param of type MovieFinder?. the choice of which MovieFinder? implementation to use for MovieFinders? was explicitly made; so PicoContainer? must have used that as the arg for MovieLister?'s constructor. By contrast, in his Spring setter injection example, the fact that MovieLister? needed a MovieFinder? did have to be explicitly declared. Clearly, I prefer to implicit introsective way.

  J's dynamic component system/implementation choosing system will have to overcome issues like this: "If you have multiple ways to construct a valid object, it can be hard to show this through constructors, since constructors can only vary on the number and type of parameters. This is when Factory Methods come into play, these can use a combination of private constructors and setters to implement their work. The problem with classic Factory Methods for components assembly is that they are usually seen as static methods, and you can't have those on interfaces. You can make a factory class, but then that just becomes another service instance. A factory service is often a good tactic, but you still have to instantiate the factory using one of the techniques here."

Fowler opines that "Of course the testing problem is exacerbated by component environments that are very intrusive, such as Java's EJB framework. My view is that these kinds of frameworks should minimize their impact upon application code, and particularly should not do things that slow down the edit-execute cycle. "

aggregation: like consultation, but the object being consulted is just some other object, which persists before and/or after the creation/destruction of the consulting object (i.e. it's not just some private object owned by the consulting object and destroyed when the consulting object is destroyed)

how does Haskell do component programming without typecasts? see: Haskell COM interface at http://www.haskell.org/hdirect/design-7.html. But that's an FFI.

toread: http://portal.acm.org/citation.cfm?id=1294920 A type-level approach to component prototyping. haskell, and also has a useful-looking basis set of functionality for component programming.

http://www.md.chalmers.se/Cs/Research/Functional/Fudgets/Intro/ Haskell GUI approach

A computational model of classical linear logic: Is classical linear logic inherently parallel? (1997)

Release 0.6 of Monadic Constraint Programming We've just released version 0.6 of the Monadic Constraint Programming framework on Hackage.

This release provides a whole lot of generic support for Finite Domain (FD) constraint solvers: a common modeling language and infrastructure for targeting different backends. Very useful if you happen to develop an FD solver and want to hook it up to our framework to benefit from its advanced search capabilities.

Users will of course be much more interested in the actual backends that we provide. Besides the basic Haskell FD solver we had before, there are now three different ways of interfacing Gecode, one of the best FD solvers out there and open source too. To get started, the examples directory shows how to model a number of well-known problems. Posted by Tom Schrijvers at 3:59 PM 0 comments Links to this post Labels: constraints, Gecode, Haskell

Monday, September 7, 2009 EffectiveAdvice?