On Wed, Oct 1, 2008 at 11:19 PM, _why <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 01, 2008 at 12:09:17PM -0400, Seth Thomas Rasmussen wrote:
>> Aha. So, after fully reading the Rules, I developed a theory that the
>> example shown there is all wrong because inside the app() block, self
>> is changed to your app, which has no @stack instance.
>
> You're totally right. The methods need to be reversed, I messed it
> up.
>
> class Messenger
> def initialize(stack)
> @stack = stack
> end
> def add(msg)
> @stack.append do
> @stack.app do
> para msg
> end
> end
> end
> end
>
> Shoes.app do
> fill "#F90"
> s = stack
> m = Messenger.new(s)
> s.button "OK" do
> m.add("TEST")
> end
> end
Oh, hmm, I suppose that is one way to do it, too. Flipping them around
solves the problem of the scope of @stack, but I kind of like it the
other way around in that it seems more intuitive to "go into the app"
first and then do stuff to it.
This Messenger example leaves me feeling funny no matter how you slice
it, though. It seems unecessarily complicated. I've been doing what I
think are similar things using simple methods on my app, perhaps added
through included modules. Bits they need to be aware of, like the
stack in this case, are just held in instance variables that the
different methods assume are setup and good to go.
Shoes.app do
@messages = stack
def add_message(text)
@messages.append do
para text
end
end
button "go" do
add_message "dy-no-mite"
end
end
I understand the idea of the example is to explain the tricky case of
self in some contexts, but maybe we can come up with a better way to
illustrate that.
> I'm not completely happy with this. It might be better just to wrap `append`
> in
> instance_eval as well. I just hate messing with scope like that.
I thought about that, too. I can understand your concern there. Tricky business.
--
Seth Thomas Rasmussen
http://greatseth.com
