World: r3wp

and glass even uses the liquid (trans)mutation feature where you 
swap classes on the fly based on oranisation of GUI

resolving is just a way to pass a bunch of vars in one shot

*parameters

yes... it just copies the values as-is from on object to another 
 like:   set in obj 'a get in obj-b 'a

I meant... aahhh yes... (just read the complete help string)

but fast

but because functions aren't re-bound... I don't see a lot of use 
for this since my dependency mechanism allows unlabeled inputs. (its 
actually used more often than labels... cause its faster right now... 
but that might change with R3, because we have much nicer binding 
control.

also unlabeled inputs use up MUCH less ram.  its just a block containing 
references to subordinates.  if we use an object, we add an extra 
overhead of obejct and binding space for each input.

with the A98 release I will be porting liquid over to R3 for sure 
(at least I'll try and see how it goes).

my last attempt did work, but much has changed in object/binding 
since then, so its probably doable now.

did=didn't

not sure, It has to be confirmed but in R3, objects sharings the 
same parent objects  have the same specs (in memory) and have only 
their data copied in a distinct frame.
BrianH could confirm that point.

Maybe my memory is bad

But IIRC Carls say something about optimization of objetcs in R3, 
long time ago

*said

that would be nice , if your memory IS good  :-)

But don't know what  happens when the object is expanded

I'll definitely run my liquid unit tests and see how R3 compares 
to R2 under heavy load ( a few hundred MBs of nodes)

(Sorry, phone calls) Processed fields are great, and accessors are 
a great, but there are at least 3 different ways of doing accessors 
(method, procedural, functional) and syntax support would only support 
the method-style accessors. And because of REBOL's object model, 
method-style accessors have a lot of memory overhead, whether they 
are supported by syntax or not. This is why R3's GUI uses procedural/functional 
accessors.

for liquid, expanding is not a big issue... liquid is totally class/instance 
based.... all liquid properties are stored, not part of the node 
itself.

for the record, brianH I agree totally.

Well in R2, you can't expand objects :)

but as I said earlier, liquid doesn't require you to "label" your 
inputs.

So my biggest practical beef with syntax-supported accessors for 
REBOL is that we are actively trying to get away from the style of 
programming that they require. My only other complaints about syntax 
support comes from many years of actually using a language with such 
support, and seeing the many downsides.

and actually, labeled inputs might link to several other nodes.  
so even there, we couldn't use expanding objects.

Now I can look at the messages above...

Urgg... where is my shelter

I didn't say anything, Actually my Cat walked on my keyboard

Steeve, REBOL in general and R3 in particular doesn't have direct 
support for parent objects; we support prototype objects instead, 
which is a completely different thing. So the body of an object isn't 
stored at all, let alone shared; instead, BODY-OF an object creates 
a brand-new block every time from a collection of the key and value 
pairs. There might be some data sharing of the words collection between 
a prototype of an object and derived objects (which might be what 
you meant) to save memory, iirc, but the values are BIND/copy'd.

That saving memory trick might have just been suggested by Carl instead 
of implemented though. It all depends on whether the overhead of 
managing the sharing exceeds the overhead saved.

The cat says he's was well aware that the values were copied elsewhere.

Well of course he is :)

I have hard time to translate his miaous

I'm trying to use the reflector names for the various concepts involved 
since it saves confusion later. What your cat was calling the "spec" 
is not the stuff returned by SPEC-OF, for instance.

In my experience it will always be worth it.   because object use 
is very heavy RAM wise and it quickly becomes slower because the 
GC can't cope with big lists of things to manage.  so although it 
might be slower in a small app (where the difference probably won't 
really show anyways) in a large application the ram savings will 
mean the GC stays agile and doesn't bog the actual processsing.


but again, new explicit tests required with R3.   everything changed 
so its up for grabs as to how a few hundred thousand object will 
crap out.

No he was talking about the words def as you expected

this summer liquid will have to scale to a few hundred million objects, 
so these things will require A LOT of attention for me.


they will not all be allocated at the same time, but they might still 
exist in the same system, with some disk or db swapping in real time, 
when things start to beef up too much.

as they are stored in memory, not like they may returned by 'reflect

Strangely enough, one of the things that needs to go on Guiseppe's 
object enhancements page is Carl's proposal to actually add a spec 
(in the SPEC-OF sense) to objects. That is the spec that he was talking 
about sharing. And that would be required to implement class-like 
behavior, syntax support for set accessors (which Carl called set-functions), 
init and destruct methods, etc.

yep the object spec will be nice to have.

It's the most important proposal of the bunch. Which is why it is 
really premature to submit that page to Carl :)

sure its the most important... I proposed it  ;-D

And it will make objects act a little more like modules, which have 
such a spec already.

funny, in the post I *didn't* add to the wiki object enhancement, 
I used the object spec as the primary example for set-accessor

As do the objects returned by SELF or BIND? applied to module contexts, 
strangely enough.

I didn't even realize I was re-using that discussion's final proposal.

How I understand objects currently. They use 2 sets of values (one 
with pointers to word's literal ) which can be shared between objects. 
A one set of values which are unique for each object.

We need to add the object spec as the *first* proposal, since all 
other proposals require it.

I agree.

Steeve, that sharing requires some kind of copy-on-write to work 
properly, and maybe hashing to really save on space. The overhead 
of those two may exceed the payoff.