Prev: Concatenating adjacent strings in a list
Next: CL to generate native docs
From: Pascal J. Bourguignon on 29 Jan 2010 19:30
Pascal Costanza <pc(a)p-cos.net> writes:

> On 29/01/2010 17:27, piscesboy wrote:
>> When is it more advantageous to write your own clojures encapsulating
>> data and functions than to use the CLOS system?
>
> Closures are more flexible with regard to capturing state: You don't
> need to anticipate in advance all the kinds of data you want to
> capture, and you don't need to make sure that all assignments to the
> relevant parts go through some specific writer functions. If you
> change your mind about details in these regards, it's a lot less work
> because the changes are typically local and ad hoc, you normally don't
> even notice that you changed something in that regard.
>
> A CLOS-based solution is more flexible with regard to the
> functionality you can provide to clients: Instead of single anonymous
> closures, you can provide multiple named functions that the client can
> select from, and in the case of CLOS, the dispatch to the actual
> method can be based on several arguments, which can get progressively
> cumbersome with just closures. However, a CLOS-based solution requires
> more planning and structuring which, depending on situation, can
> increase clarity or annoyance, or both.

Wouldn't prototype based OO merge the good points of both approaches?

--
__Pascal Bourguignon__
From: Scott Burson on 29 Jan 2010 20:54
On Jan 29, 1:37 pm, Raymond Wiker <r...(a)RAWMBP-2.local> wrote:
> If you need the extra performance, don't need
> the bells & whistles, and the use-case is simple enough, then closures
> may be a better match.

Agreed. I've used them for iterators, for example.

-- Scott
From: Pascal Costanza on 30 Jan 2010 03:24
On 30/01/2010 01:30, Pascal J. Bourguignon wrote:
> Pascal Costanza<pc(a)p-cos.net> writes:
>
>> On 29/01/2010 17:27, piscesboy wrote:
>>> When is it more advantageous to write your own clojures encapsulating
>>> data and functions than to use the CLOS system?
>>
>> Closures are more flexible with regard to capturing state: You don't
>> need to anticipate in advance all the kinds of data you want to
>> capture, and you don't need to make sure that all assignments to the
>> relevant parts go through some specific writer functions. If you
>> change your mind about details in these regards, it's a lot less work
>> because the changes are typically local and ad hoc, you normally don't
>> even notice that you changed something in that regard.
>>
>> A CLOS-based solution is more flexible with regard to the
>> functionality you can provide to clients: Instead of single anonymous
>> closures, you can provide multiple named functions that the client can
>> select from, and in the case of CLOS, the dispatch to the actual
>> method can be based on several arguments, which can get progressively
>> cumbersome with just closures. However, a CLOS-based solution requires
>> more planning and structuring which, depending on situation, can
>> increase clarity or annoyance, or both.
>
> Wouldn't prototype based OO merge the good points of both approaches?

I have to admit I'm very critical of prototype-based approaches. How do
you see they could merge the good points?


Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Tim Bradshaw on 1 Feb 2010 09:27
On 2010-01-29 17:28:09 +0000, Frode V. Fjeld said:

> I'd say "never" is a fairly good approximation.

I think that's a contentious view. I use them all the time, in fact,
because they're so lightweight to create, and you never have to think
about what needs to be captured and what doesn't (because they just
catch everything that is lexically visible).

Also closures can catch things that CLOS instances don't, such as block
names and tags:

(defun walk (object)
(block done
(do-walk object (lambda (c ...)
(case c
((done) (return-from done ...))
...)))))

From: Frode V. Fjeld on 1 Feb 2010 10:01
> On 2010-01-29 17:28:09 +0000, Frode V. Fjeld said:
>
>> I'd say "never" is a fairly good approximation.

Tim Bradshaw <tfb(a)tfeb.org> writes:

> I think that's a contentious view. I use them all the time, in fact,
> because they're so lightweight to create, and you never have to think
> about what needs to be captured and what doesn't (because they just
> catch everything that is lexically visible).
>
> Also closures can catch things that CLOS instances don't, such as
> block names and tags:

Well, I didn't say "never use closures", obviously.

In general I would expect defclass to be reasonable precisely when the
information to be captured has a static "schema", and therefore a global
declaration makes sense. In other words, I'd never prefer

(defun make-foo (..) (lambda (..) ..))

over

(defclass foo ...)

which was how I understood the original question.

> (defun walk (object)
> (block done
> (do-walk object (lambda (c ...)
> (case c
> ((done) (return-from done ...))
> ...)))))

It would never occur to me to use defclass etc. for something like
this. I suppose it could occur to someone more used to java or scheme
etc, so in that sense I'd agree that my initial answer wasn't very good.

--
Frode V. Fjeld
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Concatenating adjacent strings in a list
Next: CL to generate native docs