Re: MOP question for language lawyers: can you specialize on standard-class
"Pascal Costanza (as pc at p-cos dot net)" <[email protected]> Sat, 16 May 2026 22:18:48 +0900
| Newsgroups | gmane.lisp.lispworks.general |
|---|---|
| Message-ID | <[email protected]> |
> On 14 May 2026, at 16:50, Tim Bradshaw <[email protected]> wrote: > > I'll be even more radical: CLOS itself also suffers from the same problem to a lesser extent. Not just because OO isn't the silver bullet people thought it was, but because CLOS was less vetted than much of the rest of CL (it was dropped in more-or-less wholesale pretty late in the process), and also both contains things which it really shouldn't (what on earth is change-class & its machinery doing there? Don't answer: I know it is often used in the implementation of CLOS, but that is *not* a reason for it to exist at the user level.) and doesn't contain things that it should (I'd suggest sealing). > > No, I don't hate CLOS. Common Lisp in general has a number of features that look like they are meaningless, but can be a godsend under the right circumstances. (progv comes to mind.) It just happens to be the case that I recently implemented a library for sparse matrix operations in Common Lisp and Julia, kind of in parallel with each other, and the existence of change-class in Common Lisp made that version significantly simpler. (In that library, a sparse matrix can be represented as a tree of operations or in materialized form, and the machinery for materializing the operations uses change-class to move it from one representation to the other. In other languages, you have to use double indirection instead, which infects the whole code base. The Common Lisp version is much more elegant because of change-class.) I fully respect your opinion and highly value your perspective. It's just that in my personal, subjective experience, CLOS just works extremely well. (I say that as somebody who tries to avoid OOP features in other languages, because elsewhere, they are typically too restricted and often cause more problems than they solve.) Pascal _______________________________________________ Lisp Hug - the mailing list for LispWorks users [email protected] http://www.lispworks.com/support/lisp-hug.html