From: Cecil Westerhof on 21 Dec 2009 21:58 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 21 Dec 2009 22:55 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 22 Dec 2009 08:10 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 22 Dec 2009 13:29
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 |