[plt-scheme] cannot serialize classes with private methods

At Sun, 06 Aug 2006 01:21:21 -0400, Jon Rafkind wrote:
> > The difference between a private method and an procedure-valued field
> > is subtle, and the current syntax of `class' makes the difference too
> > subtle. The solution isn't obvious, because we want to support macros
> > in a `class' body that expand to definitions, and it's not clear
> > whether function definitions from a macro expansion should be treated
> > automatically as methods.
> >
> >   
> I probably don't have a strong enough grasp over this stuff but wouldn't
> procedure-valued fields always not be treated as methods?

What if you wrote

  (define callback (lambda (x) (void)))
  (define (set-callback c) (set! callback c))
  ...

? In this case `callback' should be a field (not a method), while
`set-callback' should be a method.

Granted, if you're writing something like that directly in a class,
then you could use something other than `define' to make `callback' a
field.

But what if those definitions were the expansion of some
`define-callback' macro, and the macro is defined for use in a general
definition context (instead of just in classes)? In that case, the
implementor of `define-callback' must use `define' for `callback', and
you still need a field when the macro is used in a class.

With the current syntax, definition-producing macros always work in a
`class' body. In some cases, you can add `public' or `private'
declarations to convert parts of the macro expansion to methods instead
of fields. Going the other way --- requiring a `private-field'
declaration --- would not always work, because the bindings produced by
a macro are not always visible outside the expansion.

Maybe it isn't important to support all definition-producing macros in
a class body; I think the jury is still out. For now, we're not ready
to impose a restriction on the way that `class' and macros are
composed.

Matthew