The idea is that they happen either before/after 'enhance' blocks, with no specified ordering between before blocks or after blocks.
In your example, the result would be either ["bar", "baz", "foo"] or ["baz", "bar", "foo"]. In that sense before/after do not compose as well as task dependencies and it's generally better design to use the latter when possible. alex On Thu, Nov 18, 2010 at 4:18 AM, Rhett Sutphin <rh...@detailedbalance.net>wrote: > Hi, > > Is the idea with these changes that you'd only be able to have one > first/firstly/before block and one last/lastly/after block? Or to ask > another way -- what would happen if you do > > task(:foo) do > puts "foo" > end > > task(:foo).before do > puts "bar" > end > > task(:foo).before do > puts "baz" > end > > ? > > Rhett > > On Nov 18, 2010, at 1:13 AM, Peter Donald wrote: > > > Or maybe before/after ala > > > > task(:foo).before do > > # block will be executed before 'enhance' blocks > > end > > > > task(:foo).after do > > # block will be executed after 'enhance' blocks > > end > > > > > > On Wed, Nov 17, 2010 at 7:14 PM, Peter Donald <pe...@realityforge.org> > wrote: > >>> I was initially thinking about do_first and do_last but though the "do" > was > >>> redundant with Ruby's do ... end notation. Do you think that's > better? > >> > >> Not greatly. Maybe firstly and lastly? > >> > >> task(:foo).firstly do > >> # block will be executed before 'enhance' blocks > >> end > >> > >> task(:foo).lastly do > >> # block will be executed after 'enhance' blocks > >> end > >> > >> That way it does not double up the "do" word and doesn't look like an > >> enumeration. > >> > >> -- > >> Cheers, > >> > >> Peter Donald > >> > > > > > > > > -- > > Cheers, > > > > Peter Donald > >