From: Cecil Westerhof on
tar(a)sevak.isi.edu (Thomas A. Russ) writes:

> Pascal Costanza <pc(a)p-cos.net> writes:
> I think Pascal's question was about why you want setting a non-existing
> property to be an error rather than just setting it? After all, usually
> when you want a property set, you really care about it being set
> AFTERWARDs, and don't really care if it had a value beforehand.

Because when you use :wiat instead of :wait, I like to get an error
instead of getting the old value when I am sure I changed it.

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
From: Kaz Kylheku on
On 2009-12-22, Cecil Westerhof <Cecil(a)decebal.nl> wrote:
> tar(a)sevak.isi.edu (Thomas A. Russ) writes:
>
>> Pascal Costanza <pc(a)p-cos.net> writes:
>> I think Pascal's question was about why you want setting a non-existing
>> property to be an error rather than just setting it? After all, usually
>> when you want a property set, you really care about it being set
>> AFTERWARDs, and don't really care if it had a value beforehand.
>
> Because when you use :wiat instead of :wait, I like to get an error
> instead of getting the old value when I am sure I changed it.

Lisp's keyword arguments to functions have a connection with property
lists, and perform this kind of checking (unless &allow-other-keys is
used).

You can exploit this by making a wrapper for your property list
manipulationg.

Keywords can be captured as a list using &rest.

;; initially empty property list

(defvar *my-plist* nil)

;; add/update values in property list
;; e.g. (set-my-property :foo 1 :bar 3)

(defun set-my-property (&rest rest &keys foo bar)
(loop for (key value) on rest by #'cddr
do (setf (getf *my-plist* key) value)))

From: Pascal Costanza on
On 21/12/2009 16:46, Cecil Westerhof wrote:
> Kyle M<kylemcg(a)gmail.com> writes:
>
>> Hmm... The spec says: "There is no way (using getf) to distinguish an
>> absent property from one whose value is default; but see get-
>> properties."
>
> When a property does not exist, nil is returned. My assumption is that
> every property has a non nil value. When I want to check for real
> because nil values are allowed, then after getting nil the getf has to
> be done with a non nil value. If it is still nil, the property
> exist. ;-]

It's better to use get-properties and check whether all three return
values are nil.


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: Drew Crampsie on
Kyle M <kylemcg(a)gmail.com> writes:

> Hmm... The spec says: "There is no way (using getf) to distinguish an
> absent property from one whose value is default; but see get-
> properties."
>
> http://www.franz.com/support/documentation/current/ansicl/dictentr/getf.htm

I don't really see that as a problem, or see the need for
get-properties in this case, as DEFAULT can be whatever you want,
including a value that cannot possibly be eq to any value held in the list :

(let* ((default (gensym))
(value (getf list key default)))
(if (eq value default)
(error "Property ~A not found in ~A" key list)
value))

I use this trick all the time.. in some cases it's clearer than
returning two values like gethash, and regardless, it works :).


Cheers,

drewc