Peter Denno wrote:
On Sunday 02 October 2005 01:54, Kenny Tilton wrote:
Thanks, that was helpful. But I am still looking for a definition that nails the distinction. A definition is a single sentence that distinguishes a concept from other concepts in the domain of discourse. ;^)
How about this:
The two define different kinds of cells:
"A c-input cell is a cell whose value may be set through explicit declarative code, such as by using setf on the slot."
(a) I think you mean procedural, not declarative (b) "such as by using setf" sounds like there is some other way, but setf is the /only/ way. Note that (setf slot-value) is a backdoor operation which bypasses and pretty much breaks the Cells contract with users. So it is not an alternative to setf, and it is a Bad Idea.
"A c-formula cell is a cell whose value is obtained through evaluation of a formula."
Note that the usual semantics of :initform do not apply when :initform is given by c-formula. Instead of just setting the value at initialization, the c-formula (an arbitrary lisp form) specifies the dynamic relationship between the slot's value and other aspects of the program state.
[It's actually this last part that is worth noting, I think. The semantics of :initform are different. IMO cells would be easier to learn had you not used :initform for the purpose of associating a formula with the slot. -- though :initform and whatever other keyword you might use to specify the c-formula would be mutually exclusive.]
I like it. We could have a :formula option on slot definitions and generate a compile-time error if both initform and formula are specified. We then must also offer a :default-formulargs, generating an error if one duplicates a :default-initarg. But then how do we resolve conflicts where one subclass specifies a default-initarg for a slot which has been given a :formula, or vice versa, or a sub--sub-class goes with a :default-formularg and a subclass went with default-initarg?
I think the problem is that :initform is actually Deeply Correct. A form is being supplied for a slot. That form itself screams that it is a formula, so there is no ambiguity. You see confusion becuase the rule does not become the slot value, but (again) the form itself (c?...) or (c-formula...) screams that it is a formula that produces values for the slot. And as you acknowledge, :intiformula would be mutually exclusive with :initform, which suggests that in some very deep sense they are the same thing and should /not/ be specified by different keywords. the mere fact that the code now has to check for both and that we have sunk into a quagmire on how to resolve disputes in the class hierarchy suggests that :initformula would be a big mistake.
i think the problem of the initform not actually becoming the slot value is a problem only for those who have never seen Cells before and have not had the briefest introduction. So I say leave it as it is an explain it. :)
k. tilton:
Last I looked, Cells-Gtk did not work much like a spreadsheet.
p. denno:
If you could find any spot where we might use cells more effectively, I'll try to fix it.
I am a little maxed out now, but:
- to a large degree, there are two things at work in a cells-gtk app. The widgets all work together nicely. Cells helps. Ain't broke, don't fix, because ideally this code becomes stable and does not get in the way of other development. (I /would/ however be concerned if this ouput setf'ing became standard practice in the second thing, application code managing app semantics amongst multiple GYI widgets
- look for output methods setf'ing c-input cells. Decide if the setf'ed slots could be written as rules.
- I myself use setf in output methods only where A depends on B and B depends on A. A scroll bar can control the text, or the text cursor positiion can decide the text. If that circumstance does not hold, look to see if the value can be expressed as a rule.