[MacRuby-devel] Using mixico to streamline HotCocoa?

[Richard Kilmer]

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
>
>> http://github.com/why/mixico/tree/master/README
>
>
> 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 at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macruby-devel/attachments/20081007/d7e9187e/attachment-0001.html