[Rake-devel] Hello and a little patch for task initialisation

[Link, Claudius]

Hello Jim,

> -----Original Message-----
> From: Jim Weirich [mailto:jim at weirichhouse.org]
> Sent: Samstag, 10. Juli 2004 03:11
...
> First regarding your name patch.  Could you demonstrate how 
> you intend 
> to use change.  It looks relatively harmless.  Task object can be 
> instantiated with non-string names, but the "name" accessor does a 
> "to_s" before returning the value.  Also the "@name" variable 
> isn't used 
> within the task class body.  But I'm a little uncomfortable 
> with letting 
> go of the concept of string-like names for tasks.  Help me understand.

I think the concept is still left in place.
The only difference is that the initialize() method of the task class (possibly inherited)
doesn't get a string but any kind of object.
The behaviour of the existing tasks does not change (AFAIK) as they use to_s
anyhow.

Ok, but why change.
In some of my tasks I need to pass argument to the called external program. Eg.
	"e:\some\path\to\a\model\model.rtmdl"
and
	"Component View::some::internal::model::path::componeten_name_target_os"
These can be different for every task.
I think encoding them like eg.
	"e:\some\path\to\a\model\model.rtmdl;Component View::some::internal::model::path::componeten_name_target_os"
is not too nice :-(

So what did is something like
------------------------
class ComponentInfo
	attr_reader  :modelPath, :componentPath
	def initialize( modelPath, componentPath )
		@modelPath = modelPath
		@componentPath  = componentPath
	end
	def to_s
		@componentPath.split( "::" ).last
	end
end

class MyTask < Task
	def initialize( ci )
		super( ci.to_s )
		# now I have access to 
		# ci.modelPath and ci.componentPath
		# ...
	end
	# I can even keep the Task::define_task
end

def myTask ci
	# ...
end

# componentList contains ComponentInfo's, the list is normally automatically created
componentList = [ComponentInfo.new( "e:\some\path\to\a\model\model.rtmdl", "Component View::some::internal::model::path::componeten_name_target_os" )]

componentList.collect do |ci|
	myTask ci
end

task :allCOmponents => componentList
------------------------


> 
> Second, regarding the delay of dependency calculation, perhaps the 
> following will help.
> 
> Task actions and dependencies can be declared separately, for example:
> 
>    task :a do ... actions go here ... end
> 
>    task :a => [... dependencies go here ...]
> 
> This opens up some interesting possibilities.  What if we 
> used one task 
> to calculate the dependencies of other tasks.  Consider the following 
> Rakefile:
> 
>      task :default => [:deps, :x]
> 
>      def calculate_deps(who)
>        puts "SLEEPING ----------------"
>        sleep(10)
>        puts "AWAKE    ----------------"
>        [:y]
>      end
> 
>      desc "Main Target"
>      task :x  do
>        puts "DOING X"
>      end
> 
>      desc "Secondary Task"
>      task :y do
>        puts "DOING Y"
>      end
> 
>      desc "Calculate the dependencies"
>      task :deps do
>        task :x => calculate_deps(:x)
>      end
> 
> Task x has no dependencies declared in the file.  Task y adds some 
> dependencies to x via a long calculation (artificially made 
> long through 
> the use of sleep).
> 
> With this Rakefile, the rake -T command executes quickly.  E.g.
> 
>      $ rake -T
>      (in /home/jim/pgm/ruby/rakemisc)
>      rake deps  # Calculate the dependencies
>      rake x     # Main Target
>      rake y     # Secondary Task
> 
> If we need to perform task x, then we can explicitly calculate its 
> dependencies ...
> 
>      $ rake deps x
>      (in /home/jim/pgm/ruby/rakemisc)
>      SLEEPING ----------------
>      AWAKE    ----------------
>      DOING Y
>      DOING X
>      $
> 
> Does this help?
Yes indeed this has the desired effect. But it somehow 
changes the nice and clear rake syntax 
 task => deps
and hides the deps.
Someone might call x directly via
 rake x

also (as deps are simply appended)
	task :x  => [ deps ] do
	end
might do the trick.

I find time I will try to explore it a bit deeper.
Sometimes things are easier in Ruby than original expected.

Regards,
Claudius