GOOPS %modify-[instance|class]

GOOPS %modify-[instance|class]

[Clinton Ebadi]

I think %modify-instance and -class should be public.

I specialized change-class and change-object-class (to the same thing, just to 
be safe because the manual says either one may be called but not both). I 
seem to have a problem: when I return the updated class, all my pointers to 
the old class are invalidated! And then it seems that GOOPS continues in an 
infinite loops updated the same objects over and over again.

goops.c is using SCM_CAR and SCM_CDR to write to the cell of memory itself. 
Maybe I could use the low level object struct and modify it somehow?
-- 
http://unknownlamer.org
The root of unspoken fear
The root grows deep in my heart
A dark cold sound tears at my life


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: GOOPS %modify-[instance|class]

[Mikael Djurfeldt]

Clinton Ebadi <clinton@unknownlamer.org> writes:

> I think %modify-instance and -class should be public.

Could you be more specific why?  These seem pretty strange and magical
to me, and might change as the implementation evolves...

> I specialized change-class and change-object-class (to the same
> thing, just to be safe because the manual says either one may be
> called but not both).

The manual shouldn't mention change-object-class since that is a
private part of the implementation.  BTW, change-class is a generic
function while change-object-class is a prociedure.

> I seem to have a problem: when I return the updated class, all my
> pointers to the old class are invalidated! And then it seems that
> GOOPS continues in an infinite loops updated the same objects over
> and over again.

Could you please explain what you want to do.  You talk about
returning an updated class.  But this only happens if one is using
change-class to change the metaclass of a class instance.  The normal
job for change-class is to change the class of an instance.

Here's an example of specialization to change-class:

(define-class <class-change-notice-class> (<class>))

(define-method (change-class (o <object>) (c <class-change-notice-class>))
  (next-method)
  (format #t "class changed for instance ~A\n" o))

(define-class c () (x) #:metaclass <class-change-notice-class>)
(define o (make c))
;;; Now we redefine c:
(define-class c () (x) (y) #:metaclass <class-change-notice-class>)
;;; If we now refer to o, it will be lazily updated:
o
-->
class changed for instance #<c 807f890>
#<c 807f890>

This seems to work.

Could you please give me enough information to reproduce the infinite
loop you are talking about?

Best regards,
Mikael Djurfeldt


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: GOOPS %modify-[instance|class]

[Clinton Ebadi]

On Friday 10 January 2003 05:12, Mikael Djurfeldt wrote:
> Clinton Ebadi <clinton@unknownlamer.org> writes:
> > I think %modify-instance and -class should be public.
>
> Could you be more specific why?  These seem pretty strange and magical
> to me, and might change as the implementation evolves...

They swap the class in place. It seems that if I don't do that then all of my 
objects that point to the class being changed remain being part of that class 
and then only new objects can be created with the changed class. My 
understanding of the MOP is a bit fuzzy so I'm probably wrong.

> > I specialized change-class and change-object-class (to the same
> > thing, just to be safe because the manual says either one may be
> > called but not both).
>
> The manual shouldn't mention change-object-class since that is a
> private part of the implementation.  BTW, change-class is a generic
> function while change-object-class is a prociedure.

See the GOOPS Manual, Mop Specification, Class Redefinition. It says "[*fixme* 
Actually it sometimes calls change-class and sometimes change-object-class, 
and I don't understand why.]" 

>
> > I seem to have a problem: when I return the updated class, all my
> > pointers to the old class are invalidated! And then it seems that
> > GOOPS continues in an infinite loops updated the same objects over
> > and over again.
>
> Could you please explain what you want to do.  You talk about
> returning an updated class.  But this only happens if one is using
> change-class to change the metaclass of a class instance.  The normal
> job for change-class is to change the class of an instance.

I meant an instance (sorry about that).

> Could you please give me enough information to reproduce the infinite
> loop you are talking about?

My code is at http://unknownlamer.org/files/temp/serialize.scm (it has other 
problems and after I get the class redefinition to work it still won't work 
but I'd just have to do one more thing). I modified it and now it says slot 
'object is unbound (I marked the line this happens at in the source). I 
didn't want anyone to see it because the code is a bit of a hack and 
sucks...(sorry for taking so long to reply but I've had to put in really long 
shifts at work the last few days)

-- 
http://unknownlamer.org


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: GOOPS %modify-[instance|class]

[Mikael Djurfeldt]

Clinton Ebadi <clinton@unknownlamer.org> writes:

> On Friday 10 January 2003 05:12, Mikael Djurfeldt wrote:
>> Clinton Ebadi <clinton@unknownlamer.org> writes:
>> > I think %modify-instance and -class should be public.
>>
>> Could you be more specific why?  These seem pretty strange and magical
>> to me, and might change as the implementation evolves...
>
> They swap the class in place. It seems that if I don't do that then
> all of my objects that point to the class being changed remain being
> part of that class and then only new objects can be created with the
> changed class. My understanding of the MOP is a bit fuzzy so I'm
> probably wrong.

class-redefinition sets things up so that any future reference to an
object of the old-class will cause it to switch to the new class.
This means that from the moment (class-redfinition old new) is called,
all objects of class old will appear as being of class new.  The
actual update takes place "just-in-time".

>> > I specialized change-class and change-object-class (to the same
>> > thing, just to be safe because the manual says either one may be
>> > called but not both).
>>
>> The manual shouldn't mention change-object-class since that is a
>> private part of the implementation.

Yes.  I've changed that now.

>> Could you please give me enough information to reproduce the infinite
>> loop you are talking about?
>
> My code is at http://unknownlamer.org/files/temp/serialize.scm (it
> has other problems and after I get the class redefinition to work it
> still won't work but I'd just have to do one more thing). I modified
> it and now it says slot 'object is unbound (I marked the line this
> happens at in the source). I didn't want anyone to see it because
> the code is a bit of a hack and sucks...(sorry for taking so long to
> reply but I've had to put in really long shifts at work the last few
> days)

I don't understand why you need to use the class redefinition protocol
in this case.

BTW, (oop goops save) seems to do something related to what you want
to do.

Since I don't understand your code, I can't deduce the intended
correct operation, so I can't understand what is not working correctly
either.  However, I did notice one bug: Your change-class method
doesn't call (next-method).  That is necessary.

Here's a further example of the protocol in operation.  That may give
some  hints:

guile> (use-modules (oop goops))
guile> (define-class c () (x #:init-keyword #:x))
guile> (define o (make c #:x 3))
guile> (define-method (change-class (o c) (new <class>))
                        (next-method)
                        (format #t "~A: ~A\n" o (slot-ref o 'x)))
guile> (define-class c () (x #:init-keyword #:x) (y))
guile> o
#<c 4076bcc0>: 3
#<c 4076bcc0>
guile> 


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: GOOPS %modify-[instance|class]

[Clinton Ebadi]

On Wednesday 15 January 2003 07:38, Mikael Djurfeldt wrote:
> BTW, (oop goops save) seems to do something related to what you want
> to do.

In fact, it does almost everything I need. I was trying to use class
redefinition to
handle cycles in objects by storing an object in a proxy object and then (at
the end of serialization) resolving all cycles by converting all remaining
proxy objects into the objects they held. The save module does what my code
used to: have each object that contains another object recieve a copy of the
object instead of a pointer to the original object (which causes problems).

The first bug was that I was using #:init-key instead of #:init-keyword.
 After fixing that it doesn't explode but still doesn't work quite right. Is
 there anyway to use the MOP to lazily update all instances of one class to
 some unspecified second class in place? I can't see anything that would
 allow me to do handle recursive cycles in objects unless I integrated the
 serializer in the GC (and therefore written in C, something I do not want to
 do).

[ten minutes later]

This new method works:

(define-method (change-class (obj <unserializing>) (new <class>))
  (format #t "change-class: ~A:~A " obj (class-of obj))
  (let ((object (slot-ref obj 'object)))
    (%modify-instance obj (shallow-clone object))))

I changed some other stuff, but if %modify-instance is made public I can very
easily handle cycles in objects and my object serializer works (I do need to
go in and make it more efficient, but the point is that it /works/). The
project that I am writing this for is supposed to be 100% Scheme, but if I
have to I'll just include a copy of %modify-instance if I have to. The only
problem I have is that if I try to serialize an unserialized object I get
"Slot `object' is unbound in object #<<unserializing1> [address]>"  which
appears to be because the class <unserializing> is now invalid (is there a
way to make it valid again?)

--
http://unknownlamer.org


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user