World: r3wp

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

So three people want change, but there's no agreement and everybody 
else doesn't care, am I right?

The only overhead added to objects would be for fields to assign 
the method! values to. The method! values themselves would just have 
their references transferred on MAKE object! - they wouldn't be BIND/copy'd. 
And if you implement them right, they wouldn't even need to be defined 
as part of the object body, or bound to the object explicitly before 
being appended.

Bolek, I'm not really one of the three people who want change - I'm 
just trying to make potential changes better and more cohesive. Carl 
is though: He made most of these proposals.

Sorry Brian, so two people want change, you're commenting and everybody 
else gives a fu...doesn't care. Does that represent current situation 
better?

no, we are discussing, it looks like no one agrees, we are just juggling 
ideas.

Hence the proposals page :)

and very few people participate in fundamental language design in 
general.    especially this one, since this is aimed at more structured 
code development and very few REBOLers now and historically do larger 
apps, where these details are most usefull.

Also, very few REBOLers try to migrate large apps written in a class-based 
OOP style, instead preferring to use REBOL semantics and only emulating 
classes where appropriate. REBOL is not an OOP language, by design; 
it is optimized for a different semantic model. You can structure 
large-scale applications based on non-OOP models if you like. You 
can't easily convert them to class-based languages though. I don't 
envy your task.

No good night for me...

I were in my bed when some strange smell has appeared.
I told myself: "it's me, nothing is happening..."
The smell continued...

I went to the lower part of myt house when the slave PC is located.
The PC turned on and the AGP card BURNING ON FIRE !

Nothing to do with REBOL3 but I told you GoodNight and I want to 
inform the community it is not a good night !

On the bright side you didn't burn the house down along with yourself.