[AMOP]
@dougmerritt @weekend_editor @sigue @abuseofnotation @screwlisp
Right now I'm thinking that the real value of _The Art of the Metaobject Protocol_ is showing one way to do metaprogramming, and object-oriented programming is merely a demonstration domain.
Of course, what begat AMOP was a desire for an approach that can cover a large part of the OOP language design space, not just one point in that space, in order to be attractive to different schools of thought.
@dougmerritt @weekend_editor @sigue @abuseofnotation @screwlisp
> no one else has been mentioning (so far as I've noticed) "The Art of the Metaobject Protocol"
Not in this thread.
Indeed, this book is a tour de force (et de magique).
> uncertain that the topic deserved such a deep analysis
The topic—maybe, maybe not, but the book is really about the metatopic, i.e. about metaprogramming, if I may abuse this prefix.
(I know this ought to be formulated more carefully.)
@weekend_editor @sigue @dougmerritt @abuseofnotation @screwlisp
> (call-next-method) is a procedural way to do this, costing an extra function call at runtime, but obviating the need for weird compilation.
And that is the costs-of-lisp-implementation consideration.
The other one is the program design consideration (including the costs of program modification), which often leads me to prefer a declarative style, but that is my point of view, there are always tradeoffs, etc.
@weekend_editor @sigue @dougmerritt @abuseofnotation @screwlisp
P.S.
If I recall correctly, freezing a set of class and generic function definitions (including the methods) precludes some operations later, like redefining a class at run time, but I don't know if this is related to your question.
Again, don't trust me.
@weekend_editor @sigue @dougmerritt @abuseofnotation @screwlisp
> a CLOS equivalent to (compile-flavor-methods), that compiles all those combined methods so they don't have to be done at load or run time?
Not in the (full¹) CLOS specification.
Speaking from uncertain memory, check it if it's important.
_________
¹ Including the parts not in the ANSI standard.
I have a very vague and insufficient memory of a non-Flavors implementation that provides something like that.
@sigue @dougmerritt @abuseofnotation @screwlisp
<">
I think the core feature is call-next-method, which can effectively be used to simulate around/before/after? (Not 100% sure it's an exact match.)
</">
Rather, the "before/after/around" approach is declarative, the `call-next-method' approach is procedural.
I can't recall a citation; I think this is even stated in the specification.
I'm afraid I'll leave a comparative analysis of the two approaches for another day 🙂.
@dougmerritt @abuseofnotation @screwlisp @sigue
> since it came up, how many CLOS features do you need?
You are right to ask.
Off the top of my head, I've needed
multiple inheritance,
multiple dispatch,
"before" and "after" methods.
Maybe I did something with method combination once or twice, but let's not count this if I can't recall properly.
But I am not a serious ("heavy-duty") #CLOS user.
If this counts, in other languages I have missed capabilities to customize object initialization.
[Red Daly's Parenscript Object System, simplified-CLOS-like.]
@abuseofnotation @screwlisp @sigue
Thank you, that is impressive.
From Stanford.
Regrettably, I don't have the time to find out the extent of simplification.
[Local generic functions.]
In fact, `generic-flet' was proposed and not adopted.
<http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Issues/iss181.html>
I am glad you found a bug 🙂.
[CLOS and JavaScript]
> parenscript obviously doesn't have its own CLOS implementation
And achieving that doesn't seem like a five-minute job...
I am not the judge of whether that work can be justified, no matter how attractive it is.
Vassil Nikolov