yeah the :set is way better.. :)
On 15 May, 10:21, Jamis Buck <[EMAIL PROTECTED]> wrote:
> If you have the time, I certainly think you're the right one to
> implement this, Gabe. You've got the real-world need, which is the
> mother of invention. :)
>
> Regarding fetch_or_default, what if it was just an option to fetch()
> that determined whether or not the variable was set to the default or
> not? Something like:
>
> foo = fetch(:bar, "hello") # returns bar or "hello", but does not
> change bar
> foo = fetch(:bar, "hello", :set => true) # sets bar to "hello" if
> bar is not set
>
> It does break the Hash-like API, but then, so would fetch_or_default,
> so I think it's fair. In general, I prefer to minimize the number of
> API calls that people would need to know, in favor of generalizing a
> single interface. It's the same philosophy behind ActiveRecord's
> "find" method, which used to be "find_all", "find_first", and so
> forth, and was later combined into the single "find".
>
> Thanks for the offer to work on this, Gabe! I think, for me, the
> biggest win is the automated documentation generation, which really
> doesn't even depend on the variable dependencies being documented. :)
> At any rate, bring it on!
>
> - Jamis
>
> On May 14, 2008, at 11:07 PM, gabe wrote:
>
>
>
> > Also, I meant to offer to help make any of the changes, just let me
> > know.. since forking is the new friending these days.
>
> > On May 15, 12:58 am, gabe <[EMAIL PROTECTED]> wrote:
> >> Yeah I like that alot. Yeah arg or argument is definitely not the
> >> right word.. Maybe "variable" or "ref" or "var" are options too.
>
> >> I think this even works (although just because you can doesn't mean
> >> you should):
>
> >> desc(<<-DESC) do |d|
> >> Here is my description...
>
> >> DESC
> >> d.references :rake, "Path to rake", :default => "rake"
> >> end
>
> >> I also had the case where I wanted the default to be the value of
> >> another variable (so you could override it, or fall back to another
> >> variable).
>
> >> d.references :sphinx_db_name, "Name of sphinx db", :set => :db_name
>
> >> which I guess was shorthand for :default => Proc.new
> >> { fetch(:db_name) }. Although as long as we are in the desc block we
> >> wouldn't need the Proc wrapper and so... I guess just a use (or edge)
> >> case to be aware of.
>
> >> Another thing I monkey patched, was to support a fetch_or_default
> >> method which set the variable to the default if it wasn't set (as
> >> opposed to returning a default value for that call only)... If that
> >> makes sense.
>
> >> --gabe
>
> >> On May 14, 5:10 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
>
> >>> That's a neat idea (and I LOVE the autogenerated documentation!),
> >>> but
> >>> I'm not sure I like adding (1) another "keyword", and (2) calling
> >>> them
> >>> arguments, when they're really just variables that the task
> >>> depends on.
>
> >>> What if this was implemented by extending the 'desc' keyword,
> >>> something like this:
>
> >>> desc do |d|
> >>> d.text "foo"
> >>> d.references :rake, "Path to rake", :default => "rake"
> >>> # ...
> >>> end
>
> >>> The original syntax would continue to work, too:
>
> >>> desc "foo"
>
> >>> This way, we could later decide that we want to document other
> >>> aspects
> >>> of the task (roles, subtasks it calls, etc.) without resorting to
> >>> further cluttering the namespace. What do you think?
>
> >>> - Jamis
>
> >>> On May 14, 2008, at 2:29 PM, gabe wrote:
>
> >>>> In the capitate gem, we added a task_arg metho to the task DSL, so
> >>>> that we could document and setup defaults for cap variables.
>
> >>>> For example,
>
> >>>> ---
>
> >>>> desc <<-DESC
> >>>> Run the migrate rake task ....
> >>>> DESC
> >>>> task_arg(:rake, "Path to rake", :default => "rake")
> >>>> task_arg(:merb_env, "Merb environment", :default => "")
> >>>> task_arg(:migrate_target, "Migration target", :default => :latest)
> >>>> task :migrate, :roles => :db, :only => { :primary => true } do
>
> >>>> current_directory = case migrate_target.to_sym
> >>>> when :current then current_path
> >>>> when :latest then current_release
> >>>> else raise ArgumentError, "unknown migration target
> >>>> #{migrate_target.inspect}"
> >>>> end
>
> >>>> run "cd #{current_directory}; #{rake} MERB_ENV=#{merb_env}
> >>>> #{migrate_env} db:migrate"
> >>>> end
>
> >>>> ---
>
> >>>>http://github.com/gabriel/capitate/tree/master/lib/recipes/merb.rb
>
> >>>> Using this info, we also generate documentation, for example:
> >>>>http://capitate.rubyforge.org/recipes/merb.html
>
> >>>> Is this a weird "extension" of cap or do you think its something
> >>>> that
> >>>> might be useful to add in?
>
> >>>> Thanks!
>
> >>> smime.p7s
> >>> 3KDownload
> > >
>
>
> smime.p7s
> 3KDownload
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
