freenode/#lisp - IRC Chatlog
Search
7:18:27
phoe
sure thing I would, since the original term "design pattern" attaches itself to things as petty as the Singleton and the Decorator
8:52:47
p_l
phoe: btw, have you read the original Design Patterns (I haven't, it's on The List)? I wonder how Smalltalk version matches up to the C++/Java cargo cult
9:45:43
dim
my understanding (which needs fact checking, conversations, actually reading the book, etc) is that Design Patterns are mostly useful when all you have is Single Dispatch and Single Inheritance ; when you have multiple dispatch and a way to compose methods yourself, I'm not sure you actually need many of the design patterns... you just don't have those problems they're solving...
9:47:31
beach
dim: Those are the design patters that are mostly described in the book. But that doesn't mean that those are the only useful design patterns, so there maybe others in languages that don't happen to need the ones from the book.
9:48:36
dim
(well I said only the first half, it would be more fair to say that I also agree with the other part you're adding)
9:49:43
dim
I think http://www.norvig.com/luv-slides.pdf could be understood as some kind of Lisp design patterns too
9:54:49
dim
oh ok I failed to remember that my feeling about design patterns and lisp actually come from that slide deck, thanks for the reminder ;-)
9:56:38
phoe
basically, some design patters may disappear as the underlying language becomes actually capable of supporting the concepts behind those patterns in better ways
10:18:29
ajithmk
What's the lisp way of saying var1[0] or var1[1] when var1 is pointer to an array of structs?
10:25:59
scymtym
norvig silently generalizes a bit and doesn't say this explicitly, but there is also the fact that OOP design patterns revolve around assigning responsibilities. and by that the OOP people mean assigning responsibilities to classes which doesn't make that much sense in a CL context
10:27:15
phoe
scymtym: yes, e.g. one can also assign responsibilities to methods in CL wrt :BEFORE/:AFTER/:AROUND - I think Norvig mentions that example in his slides
10:29:37
jackdaniel
(defclass irresponsible-class (standard-class) ((do-it-p :initform :usre :reader do-it-p)))
10:29:38
scymtym
phoe: sure, but i mean that the whole methodology is structured around "packages contain classes, classes contain methods". motivations such as avoiding "god classes" or controlling coupling between and cohesion within classes only make sense in that framework
10:31:30
scymtym
one could say that CL classes take on responsibilities of the "knowing something" kind, but "doing something" is often the more important kind
10:31:36
jackdaniel
one could argue, that auxiliary methods introduce unexpected processing steps to a person, who adds their own method, and in this sense they water down resposnibility
11:44:33
flip214
Can I parse an ALIST with DESTRUCTURING-BIND as well? Or some other CL function? (Yes, I know about ALEXANDRIA:ASSOC-VALUE)
11:47:19
jackdaniel
(destructuring-bind ((a . b) (c . d)) (list (cons 1 2) (cons 3 4)) (list a b c d)) ; works
11:48:15
jackdaniel
(loop for (a . b) in (list (cons 1 2) (cons 3 4)) collect a collect b) ; also works
11:48:43
phoe
d-b won't work on reordered alists though, it can't perform this sort of pattern matching
11:49:24
jackdaniel
I'm certain I said that that it does not know anything about keys or values, hence - about the order ,-)
11:50:38
jackdaniel
flip214: you may put CASE in the loop to match keys, or alx:switch if keys have a custom test
12:02:13
kinope
Do any of the Common Lisp implementations support assigning threads to run on specific cpu cores?
12:04:05
p_l
kinope: I don't think there's anything explicitly made in Lisp-side APIs, but you can easily use CFFI to call out necessary system-level functions