[plt-scheme] "appending" to classes rather than extending

On Wed, Mar 5, 2008 at 11:24 PM, Rob Hunter <rob.hunter at gmail.com> wrote:
>  * Why no love for the classes? The way I see it, you pay a price to
>  move into classes land in Scheme.  Suddenly your functions aren't
>  functions anymore -- they're methods which require a "send" instead of
>  just a left paren.

Agreed, and I think there are more problems.  In addition to the
"another module system" argument raised by Doug, I believe classes
don't scale down.  It is natural to start programming with structures,
and when the need for polymorphism arises switch to classes.  But
there is no easy step from structs to classes -- it is a massive jump.
 A generic function approach would be much better.

>  ** What I'm actually working on is a web app library, where the
>  implementations of the functions in the library depend on a runtime
>  value (i.e., the web server request). So, e.g., current-user might be
>  a function in the library, and it *won't* require a request as an
>  argument -- it's "built-in" dynamically.  I also want clients of the
>  library to be able to override any of the default implementations of
>  the library functions.

I'm very interested in seeing what come up with.

> This library, btw, is my attempt at striking a
>  balance in the library vs framework war.

I think this war has been vastly overstated.   For example, the blog
post you linked to says:

"With a library, your application code makes direct calls to the
library, gets back the results and does something with those results.
A framework, on the other, follows the "Hollywood principle," don't
call us, we'll call you.  With a framework, you register your code,
and when the appropriate time comes, the framework will invoke your
code to do something it expects. "

http://floatingpoint.tinou.com/2008/02/a-few-weeks-ago.html

For a start, in a world with first class functions this distinction
doesn't seem very meaningful.

N.