> directly call initialize? In any case, why is this so? Wouldn't it be > better for initialize to just get the "unpacked" argument list? This > perplexes me.
I've been thinking about this, and lurking at the tinyclos implementation, and then reading the cltl sections about initialization in clos. Despite the fact that clos make-instance indeed *apply* the initargs when calling initialize-instance, thus unpacking/destructuring the initargs list, everything in the specification seems to imply a plist style of usage. Even the name part of a name-value pair is used to choose between (i) direct initialization of the corresponding slot or (ii) calling the initialize-instance method with the name-value pair. So, all in all, the usage implied is akin to dealing with a (name value name value ...) list argument in goops or tinyclos. All this seems specifically oriented to slot initialization, not to general construction of a new instance while preserving some class invariant imposed to the internal data/slots (please, notice that my interest here is not about encapsulation or access control matters). So maybe I'm suffering from a paradigm mismatch kind of thing, as I'm trying to fit initialize into the usual OOP concept of constructor. From this perspective initialize (and initialize-instance) looks to me like erotic lingerie for slots (no pun intended, really :)), as maybe it isn't completely transparent but it's surely translucent regarding the underlying slots. The focus seems to be at a lower level of abstraction than the level the usual constructor operates in. I'm aware of virtual slots and, of course, of the possibility of implementing a custom initialize method, but these solutions only buy some degrees of freedom around the slot initializing focus: virtual slots still looks like slots and the argument to initialize is still a list, presumably of slot name-value pairs. I'm also aware of the possibility of defining read only slots but, again, this is not generally enough to offer convenient ways of construction that preserve some desired invariant. So, a question to the experienced lispers here, a question that's not specifically guile or goops or scheme related. Is the make (or make-instance) way of constructing a new instance usually exposed to the final user? Or a factory function, operating at a higher level of abstraction, is intended to wrap the lower level, slot-fillig oriented, call to make? In this case, a custom initialize method implementation should be seen more as a complement to make than as a proper constructor/factory. (Moreover, the visibility and access of constructor/factory functions are easily controlled using the module system although, as I've said before, that's not my interest here). Best regards -- Carlos
