This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> > I've seen a skeleton of the forthcoming guile object system in the new > > snapshots, probably an undocumented feature whose usage is yet strictly > > discouraged. > > Do you mean objects.[ch]? I think Mikael startet working on a object system > called "goops": > > (define cl (make-class-object <operator-metaclass> "pwpwpw")) > (set-object-procedure! cl (lambda (a . x) (display x))) > (define ob (make-struct cl 0 (make-struct-layout 'pwpwpw))) > (ob 1) -> (1) > > The problem with the current implementation is that it is based on > structs, which aren't very well designed (IMHO). In a dynamic typed > language like guile a class should be an object and vice versa. > > > > Will it be possible to access modules defined in scheme in the new built-in > > Are you talking about Objects or Modules? > > > Jost I haven't been paying much attention to any discussion about a Guile object system which might have taken place - so please forgive me if I go over well-trodden ground. I am aware of two major Object System paradigms. Multiple dispatch - behaviour is not encapsulated by classes, but rather supplied by generic functions. Alternative boundaries (e.g. modules) may be used to enforce public/private distinctions. e.g. CLOS, Dylan Single dispatch - behaviour is encapsulated by class boundaries and public/private distinctions tend to be enforced on the same boundary. e.g. Smalltalk, [Objective-]C[++], Java. There is no point in getting into a religious war about the comparative features of each one. All I ask is that whoever writes THE guile Object System takes into account that whichever he chooses he will come across people who want the other (or maybe even prototyping like Self). With this in mind we should be considering what all these paradigms have in common and building a layered framework which might support, at different levels, any conceivable variant. I am currently using tiny-clos and would be interested in any underlying framework onto which I could move the implementation to give me speed gains. The above example does not really contain enough information for me to fathom which way GOOPS is going - is there some other discussion group. I'm sure I haven't seen much posted here. Can anyone tell me more ? Have I missed something ? Jules