World: r3wp

For example, many graphical objects will be cached in their reduced 
blocks, so it's not a GC problem.

but the first one becomes a persistent object and doesn't need to 
reduce over and over.  


when the structure becomes somethings which goes beyond 50kb of draw 
source,  reducing over and over hits the GC very fast.

In addition,  REDUCE on blocks now supports REDUCE/into that generates 
no garbage.

Well... I find that most coders don't pay close attention to their 
garbage side effects, but in a GUI sysetm, it's wise to do so.

yes, but if the structure is nested, you have to reduce things so 
they become flat.


also, not all situations allow you bind values directly to objects,

Again, it really depends... because the DRAW block is constructed, 
objects are not that good of a substitute, because their only benefit 
is named fields, which in a constructed domain offer no clear advantage.

also note that I gave this example as a Draw, since we can all quickly 
see what is happening, but the above applies to many other datasets 
which are used libs, and for which objects are much more user-friendly 
than objects.


think of C libs which use deep struct trees. I'd rather keep the 
user interface object related.

Object fields primary advantage is in human domains where the named 
fields make code more clear.

yes... but they also allow context on the REBOL source side.


note that with the example above using objects, I don't need to go 
thru a draw block on the native side.  I could inspect the object 
and fire AGG (or other lib ;-) commands directly

as you say, its a case by case issue, but in most of my larger projects, 
i end up using object for a variety of management reasons.

Yes, but there is a problem in your example above in that one is 
an apple and the other an orange.

An object does not represent sequence, it represents state. A DRAW 
block represents sequence. They can be as long as you need.

So, for the above DRAW with object example to be useful, it would 
require a sequence of objects, so you're back to a block.

It's funny, I go back and forth a lot on my own designs in regard 
to object vs block.

For the human side, such as providing a style sheet containing graphics 
attributes, object is the winner. However, as that style sheet is 
processed, it is flattened into a sequence of commands sent to the 
AGG rendering engine.


Now, it's probably possible to change our API into AGG to use objects, 
and that's probably find, but I'm not sure that it's really any more 
efficient.

find = fine

true, but objects can be nested. and a single small object, like 
in the above, may actually represent MANY draw commands.
 

for example... a single block of text strings... may actually represent 
all the items of a text list.  parsing that list to fit things within 
bounds. 

re-creating the whole AGG block as you scroll the list, forces you 
to possibly generate a few hundred draw items in a block.


but you have to build that block using intepreted code, which only 
ends up being an intermediate in order to pass the visuals to the 
rendering.


with an object, constructing that visual can all be handled on the 
native side and will save a lot of work on the interpreter and the 
GC.

the object will contain a few parameters and it represents the list... 
but rendering it will all be managed in the native side.

though, as I said, this is not specifically Draw related... if I 
want to represent a node structure which has properties, methods 
as well as data, doing so using blocks is impossible to manage.

The above block of texts example is puzzling to me. Here's why... 
normally, the display is constructed from nested layers of GOBs, 
each with offsets. So, scrolling a specific area of the display does 
not require any reconstruction of the blocks.

What I find odd about your argument is that it implies that individual 
fields of objects would be selectively updated.

That means that those field references are specifically coded in 
the program... which to me means you're not really writing REBOL 
code, you're writing C++ in REBOL code.

It seems to me that the such a method result will be a program that 
is many times the size and complexity... and hence cost and brittleness.

Of course, I may not be understanding precisely your method.

(I know your code is usually nano-sized. ;)

I admit that I am one of the rare REBOLers to write what we can call 
"large" applications.

at some point, the benefits of context and object instantiation become 
invaluable.

I want to use R3 in a project that means I will need to manage hundreds 
of thousands of "things".


If I can shove all of the heavy lifting into the native side of things, 
then I use REBOL for what its good at, high-level control.  but the 
datasets might still be huge.

Only at the edges.

And, mainly at the human edge.

At the core, a CPU executes a sequence of instructions, not an object.

I guess I'd have to show you in actual code so you'd "see" it  ;-)

liquid is at the center of this, of course, but without objects, 
I coudn't easily hold state, process , cache and data together.

As far I know, Maxim don't use the nested gobs approach but reconstruct 
nested draw blocks instead.

liquid uses state to control processing.  each node is like a mini 
kernel only aware of itself.  by linking stuff together and with 
messaging, all the nodes cooperate.


right now, liquid is able to completely control a complete GUI forking 
of only the refresh of data which actually changes.  but i cannot 
implement some liquid's low-level code within extensions because 
they can't look up the nodes.

steeve, right, because in R2 there is other way to make a 100% AGG 
interface.

there is *no* other way

nested draw blocks may be slower in R3, but I see a benefit with 
Maxim's way. It allows easy composing and inheritance of transformations 
in the sub-blocks, like skewing, rotation, translation, scaling.

in R3 I could go far beyond, actually dumping some of liquid's processing 
directly in the native side of an extension.


in fact, I could use AGG or OpenGL directly without even using gobs 
or draw blocks since the interface is built by how you link things 
together and this linking and messaging will automatically fire-off 
AGG commands, without the need to go through an intermediate.

anyhow... object use is central to this, since its the most approachable 
way to group & bind things in context .

maybe you could simply convert your object into gobs ;-)

liquid is at a lower level than gobs (its not strictly gfx related) 
and I need object access for liquid (and other things).

off the topic, 

Gobs are not specifically related to graphics if they are not rendered 
(showed)

Gobs could be used to implement some efficient data structures, like 
linked list or tree.

As far I tested, dealing with structures of gobs is faster than with 
standard objets.

A really cool feature is that when a gob is append as a child to 
a gob, it's removed from its current parent automaticly.

Yes, true and useful too.

I need to find a group to discuss the PAIR changes happening. Suggestions 
anyone?

Core?

no !REBOL3

I guess. Kind of general group tho. Was hoping we had a graphics 
or datatypes group.

there's REBOL3 GUI

How to compile the sample ext-test.c using MinGW http://jira.rebolsource.net:8080/browse/REBOLKIT-5

Looks like it should be possible to call Java libraries from a C 
extension using the Java native interface ...