Re: A couple of questions about goops method parameters

[Carlos Pita <carlosjosepita@gmail.com>]

> 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