

Debugging Lisp Part 3: Redefining Classes - jorams
http://malisper.me/2015/07/22/debugging-lisp-part-3-redefining-classes/

======
wtbob
Being able to redefine classes at runtime, and having full control over what
that redefinition means, is one of the several secret powers of Common Lisp
and the MOP; it's part of why I cannot support choosing another Lisp for any
project.

------
hydandata
Lisp is often advocated for the big ideas like macros, but I personally enjoy
small things like this the most. Every day I write Lisp code I discover new
ways of making my work easier and walk away with more appreciation for the
effort that went into designing this language.

Thank you for this series, everything is expressed clearly and concisely.

------
hacker_9
Probably going to get downvoted to oblivion but redefining classes at runtime
seems like a really bad idea - surely this just leads to undefined behaviour
within your type system. If I pass an int to a method I don't expect it's type
to be changed by said method.

In addition to this, the solution given seems overly complicated for the
problem at hand (or maybe that's just Lisp OOP for you). In C# if I pass an
int to a method that can't handle a following int*int because the result will
overflow 32bits, then I'll just do a '.. new BigInt(int)' and go from there.
Why would being able to redefine int help me better?

~~~
jakub_h
> Probably going to get downvoted to oblivion but redefining classes at
> runtime seems like a really bad idea - surely this just leads to undefined
> behaviour within your type system.

Technically, databases are doing that all the time - at least the more
advanced ones like Firebird and PostgreSQL - you can transactionally change
the schema, even while the DBMS is running, and you do not expect to lose old
data in the process. The data gets even updated lazily. Interestingly, there's
at least one database (AllegroCache) that uses this similarity between heap
update and on-disk data update to great advantage to blur the distinction
between transient and permanent data further still.

> If I pass an int to a method I don't expect it's type to be changed by said
> method.

"Ints" are immutable, largely even on a meta-level. Most of them (fixnums) in
any program are even direct (not pointers), so no mutation would affect any
callers as a side effect anyway even if it were possible. At best you can
redefine methods specialized on numeric classes.

But I'm still learning these things, I hope I'm not spouting some nonsense
here.

~~~
junke
> Interestingly, there's at least one database (AllegroCache) that uses this
> similarity [...]

It is even more interesting to note that AllegroCache is a Common Lisp product
from franz.com

~~~
jakub_h
Well, of course it is a Common Lisp product. I haven't seen its internals but
I would be surprised if it didn't use the features of CLOS+MOP to that effect,
or, vice versa, if these features of CL weren't the very inspiration for that
functionality. (Well, maybe Smalltalk could also achieve a similar level of
seamlessness.)

