GOB! type

Development Datatypes
1

When creating a GOB! you can specify some values for it, or leave this empty and go for the default values like so:

>> gb: make gob! []
== make custom! [offset: 100.0x100.0 size: 0.0x0.0 alpha: 255]

And this results in

>> gb
== make custom! [offset: 100.0x100.0 size: 0.0x0.0 alpha: 255]

Where

>> gb/offset
== 100.0x100.0

>> gb/size
== 0.0x0.0

>> gb/alpha
== 255

Now when taking a closer look at the GOB! code in t-gob.c you can remark that there should be more to this standard GOB! than meets the eye. There could be a pane, content, data as well as a type and an OLD-OFFSET too.

Let us test this out:

>> gb: make gob! [data: [my data here]]
== make custom! [offset: 100.0x100.0 size: 0.0x0.0 alpha: 255]

Now remarkable enough gb on its own looks still the same

>> gb
== make custom! [offset: 100.0x100.0 size: 0.0x0.0 alpha: 255]

Yet, now this is the case:

>> gb/data
== [my data here]

So what about some of the other attributes?

>> gb/pane  
== []


>> gb/flags
== []

But not

>> gb/content
** Script Error: cannot pick content in path
** Where: console
** Near: [gb/content **]
** Line: 1

>> gb/parent
(i) Info: use WHY for error information
** Script Error: cannot pick parent in path
** Where: console
** Near: [gb/parent **]
** Line: 1

>> gb/type
** Script Error: cannot pick type in path
** Where: console
** Near: [gb/type **]
** Line: 1

But on line 93 of t-gob.c there is an initialization of TYPE going on:

GOB_TYPE(a) = GOBT_NONE;

Be it initialized as 0 (enum from reb-gob.h line 125), imo that should mean it could have been picked up.

  • What is the difference between the init of TYPE here and the other more successful inits?

  • Why is the content of the extra data information not shown when the GOB! gb is queried?

  • It would be very neat to have some kind of dictionary of functions and terminology that in the first place will point to the place where the function is defined. (This for many MACRO's, the REB*** structures, the reb******** functions).

2

Looks like you might be gathering that that when it comes to GOB!, there's not too much to get excited about.

It was an attempt to make a less expensive form of OBJECT!, by fixing the fields it could carry. Very few tests were written for it, and anything that isn't tested likely does not work.

GOB! isn't central to the questions I find interesting about the language. But it seems reasonable to want to have the ability to develop such optimized data types as extensions.

So it has not been deleted because it is an example of that. The pressure of wanting to keep it working but not "build it in" has influenced the way the extensibility of cells and series nodes work, e.g. NODE_FLAG_GC_ONE and NODE_FLAG_GC_TWO.

(Note that EVENT! is similar; but it tried to make the objects really small, e.g. the size of a cell. That's a bit more interesting of an optimization, and there is code that tests their use. So they are in better working condition, we assume.)

The GOB_TYPE() Is Internal And Part Of The Optimization

But on line 93 of t-gob.c there is an initialization of TYPE going on:

GOB_TYPE(a) = GOBT_NONE;

Be it initialized as 0 (enum from reb-gob.h line 125), imo that should mean it could have been picked up.

When you put different values into a GOB!, the type is set as part of that process.

>> g: make gob! []

>> g.text: "hello"
== "hello"

>> g
== make custom! [offset: 100.0x100.0 size: 0.0x0.0 alpha: 255 text: "Hello"]

Now, behind the scenes, the GOB_TYPE() is GOBT_STRING.

The idea is that because GOB!s were trying to be economical, they only wanted to use one platform pointer to store the data. The GOB_TYPE() is just a few bits chewed out of the header that were picked to help know how to interpret that pointer.

You can think of it like a tagged union.

Parent/Child Relationships Are Automatic

The idea behind the parent/child relationship is that GOB!s maintain that automatically, when you append/remove things:

>> gp: make gob! []

>> gc: make gob! []

>> append gp gc

>> gc.parent = gp
== true

>> gp.parent
; null

This wasn't working in Ren-C (parent access was erroring instead of returning NULL when there was no parent). But I've added that as a a test and fixed a couple of issues:

However, GOB! is Not A Priority...

I'll take a neutral stance on your research of GOB!. You can continue to delve into it to satisfy yourself with whether they represent magic or a distraction from more central work.

I'm settled in for a bit after a couple weeks of travel and hoping to get back to the issues I was previously in the middle of...

3 Likes