World: r3wp

oops.. embedded text I mean.

but all of that is not open source.

And mine is lost :(

my newer version doesn't have the schema validation process.... that 
is a very complex engine to build.   schemas and Parse traversal 
do not follow the same algorythm... so its a bitch to implement.

anyhow... the xml tools I currently have are not yet tested enough 
to be release ready.

Ok, so we have established that everyone does it their own way :)

but the rebxml tools (on rebol.org) as-is are very usefull, so some 
utf-8 support and are less buggy than rebelXML in my previous tests.

rebelxml gets confused if there is more than one path with the same 
name

it accepts the first one it finds

even if the full path is specified.

I suspect the author is no longer reboling

I remeber it also tripping on some of the XML files I gave it... 
don't remember the problems... but its error handling /recovery was 
very shaky IIRC.

You should add a comment to the discussion page if you remember.

as should i.

read above,  I don't  ;-)

at this time .. it may come back to you

that's why I said "if" ...

Using objects means i can store the functions that initialize it 
inside the object.

Not a good idea for data objects, which could number in the thousands, 
each with their own bound copy of the functions.

yes, the best method is to have some form of dtd or schema, and use 
class-based objects.

Class-based objects are emulated in REBOL.

the init is a context with one function, to which you supply the 
outer (instance) which holds the data:

my-tag: context [
	data: "tototo"
	attribute-1: "red"
	class: context [
		init: func [instance][
			instance/data: copy ""
			instance/attribute-1:  copy "blue"
		]
	]
]

to init the an instance of my-tag:

new-tag: make my-tag [class/init self]

class is shared amongst all my-tag instances, and is never bound 
to any of them, so its both very fast and very RAM efficient..  exponentially 
so with large classes.

That's what i was going to do initially, but I thought it would be 
easier to maintain if I kept the init methods inside the objects

Perhaps I'm not clear on this ....  
If I create a pharmacy object like this


pharmacy: make object! [
	name: none
	init: func [ n ][
		self/name: n
	]
]


is the init function shared by all the subsequent pharmacy instances?

it is bound each time, so if you have 2000 instances, you actually 
have 2000 times that function in ram, it adds up quickly for larger 
objects... for such a simple object, it might not be all that bad...

what's the diff between yours and mine?

my example above, will share the init function amongst all the 2000 
objects... and its going to be faster since no binding occurs... 
well only the CLASS word is bound but its content is the same in 
all instances.

with liquid the difference is staggering when over 10000 objects.

well, I doubt that I would have more than a few hundred objects... 
but ...

unclear as to why yours is shared and mine isn't

but its a large object.  still using the class system, I can allocate 
1000000 nodes using about 400MB.  with instances, 10000 obects take 
much more than that.

R2 shares objects within objects. the class is not re-created at 
each make [].

Oh ....

is it objects within objects within objects?

But then the class functions are accessed through obj/class/method 
obj, insstead of obj/method.

so if I have

pharmacy: make object! [
	address: make addressobj [ ]
]


and the address object has objects in it ... they will be shared??

Yeah.

Ouch

So, how does one create nested unique objects?

Create them using the init function ??

With explicit construction in the spec block, like this:
a: make proto [
    b: make inner-proto [...]
]

Every MAKE object! takes a spec block that is an init function, in 
effect.

so , instead of 

a: make pharmacy []

I have to 

a: make pharmacy [ address: make addressobj []]

If that is the case, perhaps I need a 'create function with each 
object, and at init time, iterate thru all the objects calling their 
create function ?

As you can see, I've never played with rebol objects before ...

If you like. The standard way of doing things in REBOL is to have 
functions that create objects, rather than constructor methods.

which is the more robust method?

In terms of maintenance?

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.