World: r3wp

for example, liquid, uses processed fields.   most of my liquids 
will normalize input, and make sure the output conforms to the spec.


the value might even be converted to a default or a generally accepted 
unknown value like an error! or none!

rebolek, that is one thing that can be enforced with accessors... 
but it might also make sure that two cooperative fields are always 
reflecitve.


if text is updated, maybe I want to set another field which rememebers 
what changed, so that the next refresh doesn't have to rebuild the 
whole face, only what is related to text.

Max, you can still use ctx: [a: 1 set-a: func [v][a: do-maxs-magic 
v]] , no?

sure, but then you have two references to the same attribute and 
setting the field doesn't use the rebol syntax for setting the field.


I do agree that in R3, since we can protect fields, at least we can 
now enforce the use of set-a and be sure its not replaced as-well.

this is already a HUGE improvement over R2, where you can haphazardly 
replace the functional accessor without realizing it.

Currently I use 'resolve a lot, to swap contexts so that I can use 
a light syntax in every functions because they are all bound to the 
same context.

I try to eradicate paths the most I can, It's uggly and slower than 
swapping contexts at some points.

Maxim your flow engine could use the same way I think

I used that technic in an GUI trial for R3, the syntax was pretty 
 light.

Paths are very slow. Using outside functions to set fields in objects 
seems much more sane from this POV.

yes, 'resolve will be extensively used in liquid R3, especially in 
my graphic kernel which uses labeled inputs exclusively.


but it still needs to use class based path access for simple speed 
and memory requirements.  each class currently gobgles up about 20k 
of ram once bound.  rebinding on the fly would be excessively slow.


liquid's lazy provides vastly supperior optimization in any case. 
 functions aren't even called in the first place ;-)

resolving is different grom binding

*from

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