On Oct 7, 2008, at 4:13 PM, Ernest N. Prabhakar, Ph.D. wrote:

Hi all,

One of the more clunky aspects of Hot Cocoa is the need to repeatedly state the object being manipulated, e.g.:

slider :frame => [100, 150, 200, 24] do |s|
  s.min = 0
  s.max = 100
  s.on_action do |sender|
    puts "Changed to #{sender.doubleValue}!"
  end
end
While I appreciate the resulting precision, the repetition feels a bit Python-esque to me. :-)
Well, it would be more like this:

slider :frame => [100, 150, 200, 24], :min => 0, :max => 100 do |s|
  s.on_action do |sender|
    ...
  end
end

But that aside, your example with _why's patch would not perform as you hope:

slider :frame => [100, 150, 200, 24] do
  min = 0
  max = 100
  on_action do |sender|
    ...
  end
end

In that example, even with mixico it would create local variables min and max, not invoke min= and max= as you may expect.  So, although on_action would work in that scenario, it would not help with attr= methods.  It would also not help with methods that require an explicit receiver like <<, +, -, etc:

you could not do:

 << view :frame => [....]

and you don't have a way to refer to the slider object either...so how do you get to that object if you need it?  You actually cannot call a min= because self.min= is called on the "outer" self object.

You could define

min(0)

by defining:

def min(value=nil)
  if value
    @min = value
    self
  else
   @min
  end
end

so:

min(5) sets @min and min returns @min

I have done this before in dsl's to provide chaining.  In that example above min(5) returns self so you can do:

min(5).max(6), etc but that's not necessarily pretty either :-)

All that said, in practice of constructing several HotCocoa apps I don't use tremendous block containment, instead I have methods like:

def main_window(&block)
  @main_window ||= create_main_window(&block)
end

private

  def create_main_window(&block)
    window(:size => [100,100], etc, &block)
  end

And I have these types of methods for several views that I create too (or arraycontrollers, etc).  So my main methods look nice and clean and the initialization of these elements:

application do |app|
  main_window |win|
    win.toolbar = main_toolbar
    ...or whatever
  end
end

Anyway, food for thought :-)

Best,

Rich




My impression was that part of the reason for this was to preserve "self" instead of using instance_eval, whic h is understandable.  However, _why has come up with a C extension called "mixico" that provides similar functionalityh via mixins, without changing self:
http://hackety.org/2008/10/06/mixingOurWayOutOfInstanceEval.html

 class Module
   def mix_eval mod, &blk
     blk.mixin mod
     blk.call
     blk.mixout mod
   end
 end


What do you think? Is this a viable option for HotCocoa, or are there other issues I'm overlooking?

-- Ernie P.


_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel