World: r3wp

OOP in a prototype-based language with function values instead of 
methods is different. Classes are emulated if need be, but don't 
always need to be. In REBOL even delegation is explicit, unlike most 
other prototype-based object languages.


For the best maintenance use factory functions that create objects 
based on standard specs. Beyond that, different models are better 
for different tasks. Sometimes you assign function values to fields, 
sometimes you use class objects, sometimes class names that are looked 
up at runtime.

I usually creat myself a new function which calls make and the  object 
init (wether class or prototype based)  if that init needs to create 
new inner objects, then its responsible for doing so.


in your case the make-xml-object  could accept an xml string and 
then call make-xml-object recursively for each element it finds.

I guess I can set the init functions to none after they've done their 
jobs ?

not much would really be gained, but it migh trigger some GC cleanup.

i wouldn't have 100s of init functions anymore .. :)

Using your method of creating a special context is going to screw 
up my obj2xml function :(

One way to do init is as open code in the object....That only "inits" 
the original object, not anything MAKEd from it. But it may be useful 
in some cirumstances, and it does not become part of the object:
    o: make object! compose [print "init" (a: 99) a: 1 b: 2]

huh?

Code in the spec block doesn't get attached to the object.

thats another ways of doing it... instead of storing reference objects 
you store reference spec blocks.

that is how its done in GLayout to assign the same setup to many 
styles.

The spec block is like an init function that goes away after it runs, 
without needing to assign none to any fields.

so graham... instead of doing: 


; note this is an object, context is a shortcut for make object! 
,  like func is a shortcut for make function!
addressobj: context [
	number: 666
	street: "styx lane"
	city: "pandemonium"
]
pharmacy: context [
	address: make addressobj [ ]
]

you do:

; note this is a block
addressobj: [
	number: 666
	street: "styx lane"
	city: "pandemonium"
]

pharmacy: context [
	address: context addressobj
]

I'm having to create nested objects 7 levels deep ...

in the later, you can add code in the addressobj which will be executed 
everytime you create an object using it.

for example: 
addressobj: [
	number: 666
	street: "styx lane"
	city: "pandemonium"
	address: rejoin [number " " street " " city]
]

does the xml structure change a lot (lists of data, alternative or 
optional elements, etc) or is it really static?

static largely

cause with rebol its easy to hack stuff up using out of the box tricks.....

something like...

>> probe load replace {#[object! [a: #[object! [b: #[object! [c: 
"%VALUE%"]]]]]]} "%VALUE%" "tadam!"
make object! [
    a: make object! [
        b: make object! [
            c: "tadam!"
        ]
    ]
]

;-)

A hack.

The XSD I'm looking at has about 30-40 complex data types

my client has a few thousand data types to cope with ;-) rebxml allows 
you to load that up pretty quickly...but not using the xsd obviously.


its parser builds up a string and then loads it.   I found it to 
be quite fast actually.  its MUCH faster than firefox, for example.

I'm creating the XML from scratch .. and not reading it in.

Maybe I need to use the factory way ..

you only need to output xml?  then that is very easy.

MUCH easier than loading it.

what is the source of data?

well, output is first, reading is the next task :)

it's all in a DB.

this is part of the xsd .. found an example http://stackoverflow.com/questions/790118/jaxb-types-problem

what I can suggest is that you build your objects like so:

xml-attribute: context [
	name: "someattr"
	value: "somevalue"
]

xml-tag: context [
	name: "FileID"
	content: []  ; a block of inner xml-tag objects
	attributes: [] ; a block of xml-attribute names
]



then all you do is nest objects in objects, filling them up item 
by item recursively using DB data.

the downside is that access either needs a wrapper func, or is done 
via indexes...


actually attributes could be an object, since their names are mutually 
exclusive within an element.

Let me understand this .. if I have an object that needs other objects 
more than 1 deep .. I can't use that to clone other objects without 
creating references instead of copies.

you can just do a mold/all load, that will in effect copy the whole 
tree along with all the series too.

I was just thinking that.

ex:

load mold/all make object! [
    a: make object! [
        b: make object! [
            c: "tadam!"
        ]
    ]
]


will effectively create a complete duplicate of the whole object 
tree.

but remember to use mold/ALL  cause otherwise you end up with gibberish...

So, I can continue to make the objects as I have been doing.  But 
just before I use it ... I load mold/all on it to ensure I have unique 
objects

ie. I load a serialized form of the object

yes.

ahh ... well problem solved :)

seems not :(

>> pharmacy: make object! [
[     name: none
[     init: func [ n ][
[          self/name: n
[         ]
[    ]
>> a: load mold/all make pharmacy []
>> probe a
make object! [
    name: none
    init: func [n][
        self/name: n
    ]
]
>> a/init "testing"
** Script Error: self has no value
** Where: init
** Near: self/name: n

if you have a function inside, I think you have to do it instead 
of load it.

functions cannot be serialized... so they have to be bound somehow.

Why not remove the self ? [not a metaphysical question in this context]
    ph: make object! [
        name: none
        init: func [n][
            name: n
        ]
    ]

seems functions can be serialized, but I don't understand why the 
self isn't being bound to the object..that is strange.

because it won't work?

ok, to use do, you must forget the /all.


so the above, minus the /all should work with self... (it does in 
my tests)