Thomas F. Burdick wrote:
Kenny Tilton writes:
Thomas F. Burdick wrote:
So ... uh, which approach do you think is worse: using a c-slot-makunbound function that works for both normal and cell-mediated slots;
In this contrast between normal and cell-mediated, does normal mean a slot specified:
:cell nilI still need to work on my Cells-related terminology; I mean this case. That way Cells-using programs could use the same makunbound for all objects, without worrying about where they came from.
OK. And you mean "all slots", as well.
Food for thought: slot-value is a back door. Not sure what that food means, tho, because for a while Cells /was/ mop-based and slot-value was not a back door. But that was slower and less portable. But those are practical concerns, not ideological. But consistency here might be a Good Thing if only for consistency's usual merits (hobgoblins notwithstanding).
More food: when slot-value was /not/ a backdoor, it was a nuisance to programming cells. I had to set a *backdoor* special to actually get the raw slot-value in Cell internals. ie, slot-value-using-class and its setter both had to (in all specializations) keep an eye out for *backdoor* access. OK, it is not the end of the world, but it may have been a Message From God, viz, that perhaps the transparency thing (making it seem as if CLOS does Cells) is a mistake: CLOS does /not/ do Cells. Cells by this thinking are not strictly an /extension/ of CLOS, but rather a distinct OO capability implemented thru CLOS. Less profoundly, should Cell internals ever care about slot bounditude, we'll be back into *backdoor* tricks.
Having to hack MCL folks' CLOSes becomes just another straw on the back at this point.
Thoughts?
kt