On Mon, Jul 17, 2006 at 11:17:49AM -0700, Brad Beveridge wrote: > 1) why is there THREAD.NAME, this looks like it isn't consistant > with the rest of the function names. The . is what I'm not liking.
I liked it - but I could get on fine with thread-name instead. It tells me immediately that it's an accessor for the name slot of a thread. This is probably a C / Java prejudice on my part, but I happen to find it useful in this context. thread-name fits with the punctuation of most other symbols. I guess there is merit in that, and there's little ambiguity. In a more complex example, if one had classes with methods object-handler.name the name of an object-handler? object.handler-name the handler-name of an object? what would object-handler-name be? Perhaps this marks me as insufficiently lispy, but in other languages the method-name has its own namespace per class. It seems unfortunate to roll the combination of (class-name method-name) into one[1] namespace *and* lose the gap between by not taking advantage of the wide variety of punctuation available in a symbol name. What's the advantage I can't see? I think this is a digression from SSC to CLOS. I'm quite new to both. > 2) would it be more flexible to pass keyword arguments to the thread > function that is require in SPAWN-THREAD? Are you referring to &allow-other-keys in | spawn-thread function &key name &allow-other-keys [Function] ? I'm guessing the other keys are to control the creation and spawning of the thread, not for passing into the function. If one needed to pass args to `function', (spawn-thread (lambda () (my-func my-args))) would do the trick. There isn't much else to pass, and the thing that calls the `function' has to avoid provoking an arg-count error. No args seems the simplest solution, for no loss of generality or coding convenience. I agreed with the rest of your mail. Matthew #8-) -- [1] ok so the objects could live in different packages, and then you have foo:object-handler-name and bar:object-handler-name to separate the two. But if you're using both packages heavily you'll :use both? That's only one namespace, as seen by the user. _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
