World: r3wp

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.

Sharing specs will be easier :)

would be nice if the spec also allowed field functions to be defined, 
which get self as first parameter.

then the spec really behaves like a class.  so its a tradeoff between 
speed or ram use.  you decide.

Maybe even implied. It should be possible once #1528 is fixed.in 
a98.

You can't access hidden fields through 'self though.

Hiding blocks new bindings, and path access creates a new binding. 
Only words bound before the hiding (or words derived from them) will 
still work.

On the other hand, there could be a new function type - perhaps called 
method! - that uses object-relative bindings, including binding 'self 
to the object and prohibiting 'self from being an explicit parameter. 
Object path evaluation would have to be modified to provide the implicit 
'self parameter, and all object bindings at the point of creation 
would be made relative to 'self. Not sure how that would work with 
hidden fields - it probably would have to not see them. And it would 
have to stack walk up the call chain at definition time to find the 
appropriate object to rebind to the dynamic object binding, and perhaps 
again at method start time to find out which object to be relative 
to. All in all a complex proposal, but that kind of thing might not 
be avoidable in REBOL's binding model.

hum... this sort of makes hiding half usable.   if self can't reach 
them, especially if you require access to the hidden field in expanded 
objects, which is a valid point IMHO.


note I understand the mechanics of why the hidding does this, but 
we are in a strange situation because of the scopeless nature of 
rebol.

It's because of the direct binding. Att definition time mostly, but 
can be done explicitly. This complicated the 'self debate too.

Actually, if you require access to the hidden fields in expanded 
objects, use accessors - the method-based ones should work :)

And I mean that they work *now* :)

adding a method! type is a viable idea, if we start adding a bit 
of class OO to R3.

yes, but you coudn't change the accessor since you'd need to rebind 
it, and in many cases, expanding objects, is about modifying how 
the internals are managed.

Strangely enough, my method proposal wouldn't even require classes 
- stack walking would do.

in any case, there can be other alternatives too.


the init could manage the hiding.  so that you can bind expanded 
objects, if you have a hold of the original class .

that's how I'd do it.

and this doesn't require any special tricks.

I would think that *designing* objects is about managing how their 
internals are managed, and *expanding* them is about using them as 
data structures.

Agreed about hiding in the init.

Although expanding and providing access to the old stuff from the 
expansion does require *one* special trick: Explicitly binding the 
expanded stuff to the old object, likely before you use the block 
for the expansion.

In theory you could add my method proposal as REBOL code that requires 
debug permissions, no native code required.

It would be faster with a new binding type though, similar but not 
identical to the type of binding used by function! contexts. Explicit 
support in the object! type wouldn't be required, nor would a spec.

true

for hiding & init , I realize that we might require an additional 
spec... init-on-instance