[DGD] Re: Strange clone_object behaviour

[harte at xs4all.nl]

Quoting your message from 12 Sep:
| Greetings people,
| 
| Sorry to bother you all again, but I've stumbled upon some strange
| behaviour, or more likely, I'm totally wrong in a few assumptions.  For as
| far as I know, clone_object() returns a clone of the argument.  And the
| object_name() of a clone should be <master_file>#<id>, right?  Well, if
| these assumptions are right, can one of you then explain to my why the
| following happens:
| 
| object_name(clone_object(FTP_USER)) = "/kernel/obj/ftp_user"
| 
| instead of
| 
| object_name(clone_object(FTP_USER)) = "/kernel/obj/ftp_user#123"
| 
| which I thought would happen?

What I would like to know is what your clone_object() efun looks like
in the auto-object, because the kfun clone_object() takes an _object_
value these days, not a string value, so assuming here that FTP_USER is
a define of a string, then clone_object() cannot have been the kfun.

As for your questions at the top: yes, clone_object() should return an
object with a  '<master_file>#<id>' type name.

| Can someone please enlighten me a bit in the above mentioned behaviour,
| 'cause I'm not sure anymore about when something is a clone and when not.
| The _F_create() function in the auto object also assumes the '#' part for
| clones, which is why my objects aren't called with create(1), but with
| create(0).  And this kinda screws up the objects I was writing.

It would screw mine too, believe me. :-)  Something's odd about your
clone_object() efun, I think.

Erwin.




List config page:  http://list.imaginary.com/mailman/listinfo/dgd