freenode/#lisp - IRC Chatlog
Search
21:07:21
alexanderbarbosa
jackdaniel: ive read practical before gentle and did not understood most of it. I am one of those dumb learners that you have to say lots of time "to get it"... practical aint for me :D
21:08:37
aeth
jackdaniel: I'm not sure what you mean by "a dominant programming paradigm". Most CL code I've seen does use standard-objects, yes, but they're mostly just used as containers, barely scratching the surface of CLOS. Maybe there needs to be a CLOS book...
21:09:58
PuercoPop
it is very good as a introduction to CLOS imho. It helped me understand the AMOP better
21:10:21
aeth
PuercoPop: I only know about The Art of the Metaobject Protocol, but Object-Oriented Programming in Common Lisp also has a Wikipedia article. https://en.wikipedia.org/wiki/Template:Common_Lisp
21:10:27
PuercoPop
https://www.amazon.com/Object-Oriented-Programming-COMMON-LISP-Programmers/dp/0201175894
21:13:44
aeth
jackdaniel: not scientific because there are lots of duplicates (different versions over time) and I don't have all of quicklisp, but in quicklisp/dists/quicklisp/software I get 338604 defun in wc -l and 182213 for defmethod. Of course, CLOS auto-generates a lot, and a lot of people wrap their defuns/defmethods in define-foo macros, so even if I had a snapshot of the current QL, that wouldn't quite work.
21:15:14
jackdaniel
another bit supporting my opinion is that pcl is usually recommended as an introductory material and it quickly moves to clos techniques
21:17:23
aeth
I wouldn't be surprised if it's about even in methods and functions, but only if you count the auto-generated accessors in defclass, since those are way more common than the auto-generated functions of defstruct. Probably still a little in favor of defun. (I get 45992 defclass and 7777 defstruct)
21:18:14
aeth
Although you'd need a better sample and a more sophisticated search that takes various defun/defmethod wrappers into account
21:19:25
jackdaniel
I'm not sure for what I'd need more sophisticated search? I'm not looking for validation. good night ,)
21:19:52
Oladon_work
jackdaniel: I think you're taking all this a bit too personally/seriously. That was a hypothetical "you" — aeth is engaging in a thought experiment. :P
21:21:07
jackdaniel
hm, I'm not taking it personally, just pointing out that all this counting doesn't make sense in light of clarificaion I gave that I speak about opinions, not metrics
21:21:36
Oladon_work
jackdaniel: it's a thought exercise — he's not actually arguing with your opinion.
21:36:26
aeth
my earlier point on CLOS, though, was that people tend to use it pretty lightly afaik, though.
21:38:22
aeth
I'm not sure "defmethod" for generics is really "using CLOS". At least not compared to some of the stuff I've seen using CLOS (I've even done some light MOP myself).
21:38:57
Oladon_work
I'd tend to agree. I've seen people using defmethod for a single method that will never have any sort of specialization, and to me that's not using CLOS either
21:39:18
aeth
Oladon_work: well, as long as it's exported, it does have some limited utility, if someone wanted to add an :after or :before or :around to it
21:40:08
aeth
But in most cases it probably just slows things down for nothing... You don't need defmethod if you're working on a standard object! Only when you need (or your users need) to use one of defmethod's features!
21:40:37
Oladon_work
I'm writing a game engine which implements the rule set of a popular tabletop RPG. The ruleset includes the concept of an "attack of opportunity", which is an interrupting event.
21:44:09
aeth
Oladon_work: I think a truly robust API for general use probably should wrap every major exported function (* yes, functions aren't exported, symbols are) in an extra method in case someone did want to before/around/after it, or define it for other, similar objects... Probably would bloat things quite a bit, though.
21:44:32
aeth
Not ideal, since it would also not override any internal function usage if it's just a layer on top of the functions... unless the methods use each other.
21:46:15
Bike
i mean, making everything exported generic functions just so that programmers can wrap methods is the basis of mop
21:48:06
Bike
most of them are things that are never called in user source, or maybe even can't be, like slot-unbound
21:49:29
aeth
Well, this would more be about defining two public APIs, where everything exported has two versions. So e.g. the method foobar* calls the function foobar. Perhaps with some of the methods going deeper so there are some interactions that can be overriden.
21:49:53
aeth
Interestingly, there is a convention for a low-level %foobar variant of foobar, but not a convention for a high-level variant of foobar!
22:23:58
pjb
aeth: it is sufficient to declare those functions as notinline, so that the user may substitute it with advices.