Re: DynamicBindingVsLexicalBinding

[phillip.lord@newcastle.ac.uk (Phillip Lord)]

Kai Großjohann <kai.grossjohann@gmx.net> writes:
> Here is a nice and straightforward application of dynamic binding (if I
> do say so myself).
>
> (defun perldoc ()
>   (interactive)
>   (require 'man)
>   (let ((manual-program "perldoc"))
>     (call-interactively 'man)))

It is a nice example, and I've done something similar myself (on
smtpauth, and w3 if I remember).


> Of course a REAL developer would provide a manual reader class with
> configurable manual reader class factories, and then use a dependency
> injection container to implement a configurable manual reader class
> factory factory.  And because convention over configuration is a good
> thing, we'll say that the ManManualReaderFactory creates "man" manual
> readers whereas the PerldocManualReaderFactory creates "perldoc" manual
> readers.  So you can write a manual reader factory factory generator
> that just generates an empty subclass of the
> AbstractManualReaderFactoryBase at runtime.  Yeah.  That would be great.
>  You would even only need a few hundred lines of code to do it.  And the
> Spring dependency injection container to go with it is only a couple MB.
>  What's not to like about this?  What?  The Emacs Lisp solution is only
> five lines of code you say?  How can this _possibly_ provide the same
> functionality that we've got with our awesome enterprisey framework?
> Hm?  Dynamic binding?  You must be kidding!


Like this class which is a bit of a classic.

http://docs.spring.io/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html

and has been described as everything wrong with Java in a single class.


None the less, I think you are hitting a strawman here; if Emacs went
entirely lexically bound, I don't think that it necessarily follows that
elisp will turn into Java.

Phil