[LRUG] Proffer and introducing constraints to Rails

[Daniel Barlow]

  On Mon, Apr 2, 2012 at 4:17 PM, Tom Stuart <tom at therye.org> wrote:

> Also, I can't think of many situations in which one sets an instance
> variable in a Rails controller (with the exception of setting up an object
> in a before_filter for use in an action - see conversations passim) for any
> reason other than exposing it to the view. I'm not convinced that changing
> "@post = foo" to some explicit means of passing the data to the view is a
> huge inconvenience.
>

I agree that from the controller's point of view it's just syntax and
"@foo=1" is just as good syntax as "proffer :foo".    But now pretend
you're the *view*: there's no way on that side of the interface to for it
to specify the data it needs. I think it'd catch a non-zero quantity of
bugs[*] if  views could explicitly declare the parameters they depend on
and bail out (instead of assuming nil) unless all are supplied.  I've used
Erector a fair bit and it does have the right idea here, imo

And though I agree that the complexity of this interface rarely reaches
levels where it actually *matters* that much, perhaps that in itself is an
artefact of the less-than-optimal convention we have here: the subconscious
cognitive burden of having to remember which variable names are important
is preventing us from designing cleaner, more expressive, more general
programs.  (Or on the other hand, perhaps the same cognitive burden is
preventing up from ballsing it up completely - who knows?).  There's an
analogy to be made here with lexical vs dynamic scope, and history came
down squarely on the lexical side of that debate the first time around.

Except for emacs lisp programmers, obviously.  But they're a special case


-dan

[*] my bugs, at least.  Your buggage may vary.

-- 
dan at telent.net
http://ww.telent.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20120404/264bb693/attachment-0003.html>