Prev: Mandatory initialization of a slot
Next: The Erik Naggum cll archive
From: Pascal Costanza on 19 Jan 2010 08:27
On 19/01/2010 14:14, Tamas K Papp wrote:
> 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.

I don't have a particularly strong opinion whether this should be
integrated with CLOS classes or not. That depends on so many other
factors, that I doubt that any kind of 'design principle' can be argued
for or against in a vacuum here. I'm just hinting at the fact that this
has been done before (several times, actually), and that people found
this beneficial.


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: Rahul Jain on 25 Jan 2010 00:56
Duane Rettig <duane(a)franz.com> writes:

> On Jan 12, 7:40 pm, Rahul Jain <rj...(a)nyct.net> wrote:
>> Duane Rettig <du...(a)franz.com> writes:
>> > Slot-unbound is simply a data error: you've failed to supply some data
>> > for your instance.  Slot-missing is a category error; you are trying
>> > to describe structure which you have not defined in your class.
>>
>> Unless you're me, writing my prototypes library. :(
>
> Assuming you're using the MOP: whatever you did to get a slot-missing
> error you could have avoided by checking for the presence of the slot
> via:
>
> (find slot-name (mop:class-slots class) :test #'eq :key #'mop:slot-
> definition-name)

Yeah, I ideally want to avoid that for performance reasons and not
replicate the same lookup that slot-value will do.

> Even without the MOP you are still not without recourse: since slot-
> missing is a generic-function, you can define a method via a subclass
> or mixin which defines any different behavior, thus avoiding the
> error.

The problem is that I want multiple inheritance of delegates, so I need
to loop over them, searching for the requested slot. I do define a
slot-missing method, but I need to detect and ignore slot-missing of the
delegates while I'm searching through them.

--
Rahul Jain
rjain(a)nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Thomas A. Russ on 25 Jan 2010 13:12
Duane Rettig <duane(a)franz.com> writes:
> Assuming you're using the MOP: whatever you did to get a slot-missing
> error you could have avoided by checking for the presence of the slot
> via:
>
> (find slot-name (mop:class-slots class) :test #'eq :key #'mop:slot-
> definition-name)

Wouldn't it be simpler to just use the SLOT-EXISTS-P predicate, which
doesn't depend on the MOP being present?

(slot-exists-p object slot-name)

--
Thomas A. Russ, USC/Information Sciences Institute
From: Duane Rettig on 25 Jan 2010 14:55
On Jan 25, 10:12 am, t...(a)sevak.isi.edu (Thomas A. Russ) wrote:
>  Duane Rettig <du...(a)franz.com> writes:
>  > Assuming you're using the MOP: whatever you did to get a slot-missing
>  > error you could have avoided by checking for the presence of the slot
>  > via:
>  >
>  >  (find slot-name (mop:class-slots class) :test #'eq :key #'mop:slot-
>  > definition-name)
>
> Wouldn't it be simpler to just use the SLOT-EXISTS-P predicate, which
> doesn't depend on the MOP being present?
>
>   (slot-exists-p object slot-name)

Of course, if you have the name of the slot you want. But I was
replying to someone who mentioned a prototype library, which might
imply that slot names are processed by grabbing them out of the
class. This implies some kind of access to class-slots anyway, and so
slot-exists-p wouldn't be necessary in that situation.

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