World: r3wp

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.

I find REBOL very well suited to large app dev.


you can tailor every aspect of your system to the exact requirements 
and your not forced down a path which makes no sense.


you just have to think for yourself a little more, cause you've actually 
got much more options

there was a page somewhere (wiki or blog), which described various 
way to create objects from source, allowing us to share (or not) 
subobjects etc. - anyone remembers the link?

How do you use reflection to ascertain the contents of a gob? I tried 
values-of, words-of, foreach forall - all give errors:

>> a: make gob! [text: "gob a"]       

  == make gob! [offset: 0x0 size: 100x100 alpha: 0 text: "gob a"]

>> b: make gob! [text: "gob b"]        

  == make gob! [offset: 0x0 size: 100x100 alpha: 0 text: "gob b"]

>> c: make gob! [text: "gob c"]         

== make gob! [offset: 0x0 size: 100x100 alpha: 0 text: "gob c"]

>> d: make gob! [text: "gob container"] 

 == make gob! [offset: 0x0 size: 100x100 alpha: 0 text: "gob container"]

>> append d [a b c]                   

   == make gob! [offset: 0x0 size: 100x100 alpha: 0 text: "gob container"]

>> first d

== make gob! [offset: 0x0 size: 100x100 alpha: 0 text: "gob a"]

>> foreach gob d [print gob]

** Script error: foreach does not allow gob! for its data argument

>> forall d [probe first d

]
** Script error: invalid argument: make gob! [offset: 0x0 size: 
100x100 alpha: 0 text: "gob container"]

** Where: forall

** Near: forall d [probe first d]

>> values-of d

** Script error: cannot use reflect on gob! value

** Where: reflect values-of

** Near: reflect :value 'values

>> words-of d

** Script error: cannot use reflect on gob! value

** Where: reflect words-of

** Near: reflect :value 'words

did you try  'SPEC-OF  ?


I am currently clueless as to R3 gobs, but its another test you might 
do while you're at it.

reflection does not seem to work on gobs yet.

No but ....
>> spec-of d

** Script error: cannot use reflect on gob! value

** Where: reflect spec-of

** Near: reflect :value 'spec

that sucks :-) CC it :-)

Peter, you can get GOB's length:

>> a: make gob! []
== make gob! [offset: 0x0 size: 100x100 alpha: 0]

>> b: make gob! []
== make gob! [offset: 0x0 size: 100x100 alpha: 0]

>> c: make gob! []
== make gob! [offset: 0x0 size: 100x100 alpha: 0]

>> append a b append a c
== make gob! [offset: 0x0 size: 100x100 alpha: 0]

>> length? a
== 2

>> repeat i length? a [probe a/:i]
make gob! [offset: 0x0 size: 100x100 alpha: 0]
make gob! [offset: 0x0 size: 100x100 alpha: 0]
== make gob! [offset: 0x0 size: 100x100 alpha: 0]