From: Benjohn Barnes <benjohn@...>
Date: 2006-04-27T15:59:36+09:00
Subject: Re: Rake task dependeny vs. method call


On 26 Apr 2006, at 19:26, Trans wrote:

> Thanks Ara and Joel. I see now that I have to take more care use  
> tsort or equiv.
> to get the dependencies right.
>
> I wonder though, might this task "pattern" merit low-level support  
> in Ruby. I
> don't mean in Ruby source neccessarily, I just mean that #task  
> might be
> generally useful in classes and modules, like implemented here, as  
> opposed to
> being relegated to use in Rake only.

 From the work I've been doing recently, I certainly think that this  
kind of dependency is a general concept (and I agree that it feels  
related to dependency injection, or what I know of it anyway. It also  
feels related to event driven programming models and the publisher  
subscriber pattern).

I've been looking at systems for automatic testing of other bits of  
software. Within this space, you very often need to specify that  
something happens after something else has happened (you need your  
program running to test that it does something; you need to receive a  
message before you can check it; you need to put things in to the  
database before you can expect the program to do anything; you need a  
database built before you can put things in to it; etc).

Openess seems to be very useful too. It's useful to be able to leave  
the implementation of a task open so that it can be extended  
somewhere else. For instance, you may have a general idea of "prepare  
the database". For all tests, this would do basic set up (and may  
require the database instance to be created). Some tests may add more  
functionality in to this place holder for getting their particular  
database requirements in place.

As another example, you may have the basic concept of receiving a  
message. In some situations you may want to always do something extra  
every time a message is received: log it binary as well as in human  
readable form; or check it against an expected series of messages, as  
examples.

A final concept is that tasks aren't always singletons (in the design  
pattern sense, rather than Ruby virtual class sense). You quite often  
want to describe the properties of groups of tasks that can be  
reused. This is like Rake's pattern tasks I think (I'm sorry, I'm not  
familiar with the terminology) that will turn (for instance) any '.c'  
in to a '.o'. A general system would need a general means of  
parameterising the tasks.

I've been jumping in and out of wanting to use this, but I just don't  
understand it well enough at the moment. Our project's implementation  
is quite event driven, but we certainly don't have anything like a  
framework for doing this. I'm sure there's something there waiting to  
be discovered, but I think it's more sensible to iterate to it... I'm  
convinced that the idea has a lot of general applications.

Oh, and one last thing... within testing particularly, it's useful to  
have tasks that know how to clear themselves up when they are no  
longer needed. Perhaps this is a case of a task that (if run) will  
require another clean up action to be run at some future time.

Sorry this is brain dumpy - it's interesting to see that other people  
are having similar ideas though, so perhaps it'll spark something  
somewhere :)

Cheers,
	Benjohn