World: r3wp

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]

Thanks Rebolek.

It seems that the basic series functions all work on Gob!s:

>> until [probe first d d: next d tail? d]
 
make gob! [offset: 0x0 size: 100x100 alpha: 0 text: "gob a"]

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

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

but its not in the series! list:

>> series? make gob! []
== false

But the "series" action!s have gob! in their spec.

This is the first time that I've taken a look at gob!s (an unpleasant 
thought for a genuine native English speaker), it seems that once 
you've inserted a gob! into a gob! you lose the ability to directly 
address the gob! and have to use "DOM-type" crawling to get at them. 


I'm sure I've overlooked something and would be happy to learn what.

You can adress it directly without problem:

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

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

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

>> b/text: "hello"
== "hello"

>> a/1/text
== "hello"

Thanks again Rebolek - I hadn't worked that out as the probe results 
led me to believe that the append had an implicit copy as it seems 
to do for blocks:

>> a: []      

== []


>> b: [1 2 3] 

== [1 2 3]


>> append a b 

== [1 2 3]


>> a

== [1 2 3]


>> b/1: 4

== 4


>> a

== [1 2 3]

Actully there's no copy in append - you're appending only values 
of 'b to 'a, not 'b. See this:

>> a: []
== []
>> b: [1 2 3]
== [1 2 3]
>> append/only a b
== [[1 2 3]]
>> b/1: 4
== 4
>> a
== [[4 2 3]]

..but isn't it a copy of the value when you use append:

>> a: copy ""                            

== "


>> b: 
hello"                           
 
== "hello"


>> append a b

== "hello"


>> b/1: #"j"

== #"j"


>> b

== "jello"


>> a

== "hello"

I've also found that the gob! pane field provides a neater way of 
iterating through the gob!s inside a gob!:

>> foreach gob d/pane [probe gob]

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

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

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

Cool, I thought there was something like that Peter :)

but there is a memory overhead, so take it with care... (actually 
it's not suited for intensive computings inside a GUI,, just my opinion)
>> same? d/pane d/pane
== false

Giuseppe - Ouch!

Missing 'forall for gobs

It should be possible to have FOREACH iterate through the pane of 
a gob directly. I'll request it, or see if such a request is there 
already. FORALL wouldn't be possible because a gob pans has no position.

not agree
find works with gobs, allowing things like:
>> remove find gob-parent gob
So, a position is somewhere

However, if you are doing intensive computing with gobs with REBOL 
code, a simple creation of a block of references to the existing 
gobs isn't that much overhead, compared to most REBOL operations. 
Gobs are designed to be efficient to compute by native code at display 
time, not for REBOL code.

Scrolling a pane with hundred of gobs, that's what i call intensive. 
And it 's not rare use case to my mind.

Hence the FOREACH suggestion.

A98 is somehow dalyed, isn't it?

somehow...

It's possible that it was delayed already because of some host kit 
blockage, and we got all of the 'self and bug fix goodness while 
Carl was thinking it through. I'm not worried yet.

the hostkit extraction is a pretty huge endeavour, because he has 
to change the core model and open it up much more.


the GUI pokes at just about every level into the core things like 
actions (callbacks into the core), devices, object access, these 
can't be side-stepped IMHO.


yes the A98 (or whichever release fully extracts view from the core 
as an extension), will be the mother of all releases.   The only 
REBOL release I have been waiting for... for over a decade.

Tickets #1595, #1596, #1597, #1598 and #1599 added, and #810 finally 
has some test code. Sorry, I didn't know before that gobs had reference 
position :)