-Robin
--
Lojban Reason #17: http://en.wikipedia.org/wiki/Buffalo_buffalo
Proud Supporter of the Singularity Institute - http://singinst.org/
http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/
Sure. You can always downgrade a slot to a GF, but not a GF to a slot.
Because GFs have class-level granularity, whereas slots have
instance-level. So by providing a slot up front, we avoid requiring you
to specialize and add the slot when you need instance-level granularity.
Note that because selector-on-dispatch is the standard value of
on-dispatch for selector, you can define methods on selector-on-dispatch
that do as you like.
If you must affect every dispatcher regardless of the value of
on-dispatch, you can override dispatcher-on-dispatch:
;; well I want to do like the around thing, you know
(defmethod dispatcher-on-dispatch :around (inst)
(let ((inner (call-next-method)))
(lambda (inst tokens)
(if hmm-go-ahead
(funcall inner inst tokens)
(no-me-first inst tokens)))))
--
I write stuff at http://failex.blogspot.com/ now. But the post
formatter and themes are terrible for sharing code, the primary
content, so it might go away sooner or later.
How?
> Note that because selector-on-dispatch is the standard value of
> on-dispatch for selector, you can define methods on
> selector-on-dispatch that do as you like.
Yep; my tutorial describes that.
> If you must affect every dispatcher regardless of the value of
> on-dispatch, you can override dispatcher-on-dispatch:
>
> ;; well I want to do like the around thing, you know
> (defmethod dispatcher-on-dispatch :around (inst)
> (let ((inner (call-next-method)))
> (lambda (inst tokens)
> (if hmm-go-ahead
> (funcall inner inst tokens)
> (no-me-first inst tokens)))))
*Huh*. I hadn't realized, or had forgotten, that auto-created
accessors were methods. Thanks.
I handwaved this; it's effective when you define accessors for all your
slots and (almost) always access through the accessors. This is also
the convention in Smalltalk.
For example, dataedit has allow-add-p and allow-delete-p slots with
accessors. But mine ought to change depending on the state in the rest
of the system. While Cells would be a cleaner solution, I have to make
do with methods, so I define methods on those accessors that just ignore
the slot value and figure permissions out themselves, and take care to
shotgun mark-dirty through the widget tree when certain state changes
happen.
Even if dataedit-allow-add-p et al weren't backed by a slot in their
default implementations, I'd still have to write these methods just the
same. So you gain nothing by not sticking real slots behind things that
look like accessor methods.
>> Note that because selector-on-dispatch is the standard value of
>> on-dispatch for selector, you can define methods on
>> selector-on-dispatch that do as you like.
>
> Yep; my tutorial describes that.
From what I saw, your tutorial shows call wrapping, which would be
necessary if the navigation widget user didn't want to extend a class,
but not so otherwise. Instead of
(setf (dispatcher-on-dispatch nav)
(lambda (&rest args)
(describe args) ;; YOUR CODE GOES HERE
(apply #'selector-on-dispatch args)))
you ought to write
(defmethod selector-on-dispatch ((self my-navigation-or-selector) tokens)
(describe (list obj tokens)) ;; YOUR CODE GOES HERE
(call-next-method))
Of course, this only applies if you don't need easy per-instance
on-dispatch, which of course only a slot can give you.
Off topic for a moment, your wiki writes:
> (lambda () ...) is a valid Weblocks widget. It is expected to run
> with-html. Whether with-html actually returns html or renders it
> itself, I'm not clear, but this is how you just present some straight
> html.
with-html writes to *weblocks-output-stream*. This is what any function
used as a widget needs to do, and what all render-widget-body methods
ultimately do as well.
Oh, OK. Got it. Thanks.
> you ought to write
>
> (defmethod selector-on-dispatch ((self my-navigation-or-selector) tokens)
> (describe (list obj tokens)) ;; YOUR CODE GOES HERE
> (call-next-method))
Stole it and gave you props. :)
> Off topic for a moment, your wiki writes:
>
> > (lambda () ...) is a valid Weblocks widget. It is expected to run
> > with-html. Whether with-html actually returns html or renders it
> > itself, I'm not clear, but this is how you just present some straight
> > html.
>
> with-html writes to *weblocks-output-stream*. This is what any function
> used as a widget needs to do, and what all render-widget-body methods
> ultimately do as well.
Thanks again. :)