Prev: Mandatory initialization of a slot
Next: The Erik Naggum cll archive
From: Pascal Costanza on 19 Jan 2010 04:59
On 19/01/2010 09:49, Nicolas Neuss wrote:
> Nicolas Neuss<lastname(a)math.uni-karlsruhe.de> writes:
>
>> mixin introducing a property slot:
>> (defclass property-mixin () ... )
>>
>> ;;; Interface 1
>> (defun get-property (object property) ... )
>> (defun (setf get-property) (value object property) ...)
>>
>> ;;; Interface 2 accessing properties as slots
>> (defmethod shared-initialize :after ((object property-mixin) slot-names
>> &rest initargs&key&allow-other-keys) ...)
>> (defmethod slot-missing (class (object property-mixin) slot-name
>> (operation (eql 'slot-value))&optional new-value) ...)
>> ...
>
> Since noone did take this up, I only want to remark that I am still not
> convinced that the idea of generating new slots/properties dynamically
> is a good idea in general. Part of the purpose of a class is a
> definiion of a clear interface which is mostly lost by this technique.
> I think it depends much on your programming style if you can really
> profit from that feature.

This can be useful in certain kinds of AI applications, where you want
to model information about entities, but don't know yet all the kinds of
information you may figure out in the long run. I'm by far no expert in
that field, but if I understand correctly, the frame-based knowledge
representation systems developed in the 70's did this, and had a strong
influence on the design of CLOS and its MOP. This is no big surprise
because Daniel Bobrow was involved in the development of both such
frame-based systems and LOOPS/CLOS. Originally, dynamic slots were
planned as a core feature of CLOS, but got removed "because it's easy to
implement them when you have a MOP". [1]

Daniel Bobrow was very influential in the CLOS design. For example, he
pushed for EQL specializers as well...


Pascal


[1] not an exact quote, but paraphrased.

--
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: Pascal Costanza on 19 Jan 2010 05:01
On 19/01/2010 10:59, Pascal Costanza wrote:
> On 19/01/2010 09:49, Nicolas Neuss wrote:
>> Nicolas Neuss<lastname(a)math.uni-karlsruhe.de> writes:
>>
>>> mixin introducing a property slot:
>>> (defclass property-mixin () ... )
>>>
>>> ;;; Interface 1
>>> (defun get-property (object property) ... )
>>> (defun (setf get-property) (value object property) ...)
>>>
>>> ;;; Interface 2 accessing properties as slots
>>> (defmethod shared-initialize :after ((object property-mixin) slot-names
>>> &rest initargs&key&allow-other-keys) ...)
>>> (defmethod slot-missing (class (object property-mixin) slot-name
>>> (operation (eql 'slot-value))&optional new-value) ...)
>>> ...
>>
>> Since noone did take this up, I only want to remark that I am still not
>> convinced that the idea of generating new slots/properties dynamically
>> is a good idea in general. Part of the purpose of a class is a
>> definiion of a clear interface which is mostly lost by this technique.
>> I think it depends much on your programming style if you can really
>> profit from that feature.
>
> This can be useful in certain kinds of AI applications, where you want
> to model information about entities, but don't know yet all the kinds of
> information you may figure out in the long run. I'm by far no expert in
> that field, but if I understand correctly, the frame-based knowledge
> representation systems developed in the 70's did this, and had a strong
> influence on the design of CLOS and its MOP. This is no big surprise
> because Daniel Bobrow was involved in the development of both such
> frame-based systems and LOOPS/CLOS. Originally, dynamic slots were
> planned as a core feature of CLOS, but got removed "because it's easy to
> implement them when you have a MOP". [1]
>
> Daniel Bobrow was very influential in the CLOS design. For example, he
> pushed for EQL specializers as well...
>

BTW, there is a nice historical piece at
http://www2.parc.com/istl/members/stefik/ - click on LOOPS in the menu
on the right...


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: Tamas K Papp on 19 Jan 2010 07:18
On Tue, 19 Jan 2010 10:59:48 +0100, Pascal Costanza wrote:

> On 19/01/2010 09:49, Nicolas Neuss wrote:
>> Nicolas Neuss<lastname(a)math.uni-karlsruhe.de> writes:
>>
>>> mixin introducing a property slot:
>>> (defclass property-mixin () ... )
>>>
>>> ;;; Interface 1
>>> (defun get-property (object property) ... ) (defun (setf get-property)
>>> (value object property) ...)
>>>
>>> ;;; Interface 2 accessing properties as slots (defmethod
>>> shared-initialize :after ((object property-mixin) slot-names
>>> &rest initargs&key&allow-other-keys) ...)
>>> (defmethod slot-missing (class (object property-mixin) slot-name
>>> (operation (eql 'slot-value))&optional new-value) ...)
>>> ...
>>
>> Since noone did take this up, I only want to remark that I am still not
>> convinced that the idea of generating new slots/properties dynamically
>> is a good idea in general. Part of the purpose of a class is a
>> definiion of a clear interface which is mostly lost by this technique.
>> I think it depends much on your programming style if you can really
>> profit from that feature.
>
> This can be useful in certain kinds of AI applications, where you want
> to model information about entities, but don't know yet all the kinds of
> information you may figure out in the long run. I'm by far no expert in

So why not just use a plain vanilla hash table? :-)

Tamas
From: Pascal Costanza on 19 Jan 2010 07:59
On 19/01/2010 13:18, Tamas K Papp wrote:
> On Tue, 19 Jan 2010 10:59:48 +0100, Pascal Costanza wrote:
>
>> On 19/01/2010 09:49, Nicolas Neuss wrote:
>>> Nicolas Neuss<lastname(a)math.uni-karlsruhe.de> writes:
>>>
>>>> mixin introducing a property slot:
>>>> (defclass property-mixin () ... )
>>>>
>>>> ;;; Interface 1
>>>> (defun get-property (object property) ... ) (defun (setf get-property)
>>>> (value object property) ...)
>>>>
>>>> ;;; Interface 2 accessing properties as slots (defmethod
>>>> shared-initialize :after ((object property-mixin) slot-names
>>>> &rest initargs&key&allow-other-keys) ...)
>>>> (defmethod slot-missing (class (object property-mixin) slot-name
>>>> (operation (eql 'slot-value))&optional new-value) ...)
>>>> ...
>>>
>>> Since noone did take this up, I only want to remark that I am still not
>>> convinced that the idea of generating new slots/properties dynamically
>>> is a good idea in general. Part of the purpose of a class is a
>>> definiion of a clear interface which is mostly lost by this technique.
>>> I think it depends much on your programming style if you can really
>>> profit from that feature.
>>
>> This can be useful in certain kinds of AI applications, where you want
>> to model information about entities, but don't know yet all the kinds of
>> information you may figure out in the long run. I'm by far no expert in
>
> So why not just use a plain vanilla hash table? :-)

....because you may want to combine this with other features, like
functions that are triggered on slot changes. That's simpler once you
implement this as a 'real' language construct.

Yeah, I suppose you could also implement all of this in assembly
language... :-P


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: Tamas K Papp on 19 Jan 2010 08:14
On Tue, 19 Jan 2010 13:59:51 +0100, Pascal Costanza wrote:

> On 19/01/2010 13:18, Tamas K Papp wrote:
>> On Tue, 19 Jan 2010 10:59:48 +0100, Pascal Costanza wrote:
>>
>>> On 19/01/2010 09:49, Nicolas Neuss wrote:
>>>> Nicolas Neuss<lastname(a)math.uni-karlsruhe.de> writes:
>>>>
>>>>> mixin introducing a property slot:
>>>>> (defclass property-mixin () ... )
>>>>>
>>>>> ;;; Interface 1
>>>>> (defun get-property (object property) ... ) (defun (setf
>>>>> get-property) (value object property) ...)
>>>>>
>>>>> ;;; Interface 2 accessing properties as slots (defmethod
>>>>> shared-initialize :after ((object property-mixin) slot-names
>>>>> &rest initargs&key&allow-other-keys) ...)
>>>>> (defmethod slot-missing (class (object property-mixin) slot-name
>>>>> (operation (eql 'slot-value))&optional new-value)
>>>>> ...)
>>>>> ...
>>>>
>>>> Since noone did take this up, I only want to remark that I am still
>>>> not convinced that the idea of generating new slots/properties
>>>> dynamically is a good idea in general. Part of the purpose of a
>>>> class is a definiion of a clear interface which is mostly lost by
>>>> this technique. I think it depends much on your programming style if
>>>> you can really profit from that feature.
>>>
>>> This can be useful in certain kinds of AI applications, where you want
>>> to model information about entities, but don't know yet all the kinds
>>> of information you may figure out in the long run. I'm by far no
>>> expert in
>>
>> So why not just use a plain vanilla hash table? :-)
>
> ...because you may want to combine this with other features, like
> functions that are triggered on slot changes. That's simpler once you
> implement this as a 'real' language construct.
>
> Yeah, I suppose you could also implement all of this in assembly
> language... :-P

I think that you misunderstood my comment. Sure, you might as well
wrap this construct up as a class, especially if you want it to do
other things; that's generally a good idea. But that's another
issue---you can still decide whether you want this construct to mimic
the behavior of a plain vanilla CLOS classes, or have a different
interface.

Here, I would tend to follow the design principle suggested by Nicolas
and make a different interface for this construct. I am happy to
recognize the fact that some people like to keep things uniform---eg
some languages would use [] as accessor syntax for all kinds of
collections. It is not even unlispy, Arc tries to have uniform
accessors. But I would prefer not using CLOS slot accessors for these
dynamic slots.

That said, I think that it is a good thing that CLOS can be made to do
this rather easily, and seeing an example of it was enlightening.

Tamas
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Mandatory initialization of a slot
Next: The Erik Naggum cll archive