Hi,
I don't quite understand the purpose of the 'id' member in MutableVals
and I was hoping someone could explain it to me, particularly what the
unique ID stuff is all about. In Val.h I read
// Each MutableVal gets a globally unique ID that can be used to
// reference it no matter if it's directly bound to any user-visible
// ID. This ID is inserted into the global namespace.
Why is this global namespacing done?
Thanks!
Christian.
It's for synchronizing values across multiple Bro's.
Let's say we have a table of type "table[count] of some_record". If
two Bros are synchronizing this table across them, they are supposed
to always see the same table content. In particular, if Bro A
modifies a field of some of the records, the change has to appear in
the table of Bro B. That means that Bro A has to propagate the
information "change field x of this record" to Bro B. But for this,
we need a name for "this record" on which both sides agree. That's
where the global namespace is needed. You can see these names as
something like pointers which are globally valid. (In this simple
case, we could have used the table's index as the record's name, but
that doesn't work anymore if aliasing is involved; e.g., the same
record instance is contained in more than one table).
Hope this helps,
Robin
> Why is this global namespacing done?
It's for synchronizing values across multiple Bro's.
Ah!
Let's say we have a table of type "table[count] of some_record". If
two Bros are synchronizing this table across them, they are supposed
to always see the same table content. In particular, if Bro A
modifies a field of some of the records, the change has to appear in
the table of Bro B. That means that Bro A has to propagate the
information "change field x of this record" to Bro B. But for this,
we need a name for "this record" on which both sides agree. That's
where the global namespace is needed. You can see these names as
something like pointers which are globally valid. (In this simple
case, we could have used the table's index as the record's name, but
that doesn't work anymore if aliasing is involved; e.g., the same
record instance is contained in more than one table).
Okay it's much clearer now, thanks! I guess what's still confusing me is
why is this happening at the MutableVal level and not in Vals directly?
Why does the synchronization need to be aware of the fact that the
synchronized val happens to be sitting in some kind of MutableVal?
I think this also comes back to the properties in MutableVals that I
don't quite understand -- why are these not attributes?
Thanks again, and sorry for the bombardment -- it's the subtleties I'm
coming across trying to get records to work in Broccoli ... I can
receive them but right now I'm mass-murdering Bros whenever I send them
Cheers,
Christian.
Okay it's much clearer now, thanks! I guess what's still confusing me is
why is this happening at the MutableVal level and not in Vals directly?
Basically it's just an optimization. We could just as well assign
global names to all values -- but we don't need to. A global name is
only required when a Val can actually be changed. If it can't, it
will never be referenced by one of the operations transfered during
synchronization (for example, an assignment to an integer always
creates a new Val and destroys the old one).
Optimizing even further, we need only assign global names to MutableVals
which are actually synchronized (or, in the future, persistent).
I think this also comes back to the properties in MutableVals that I
don't quite understand -- why are these not attributes?
Which kind of attributes are you refering to? (The term "attribute"
is quite is overloaded in Bro...). The attributes which are
associated with Vals are RecordVals which don't really fit here
(frankly, right now I can't remember what they are for... :-). The
attributes associated with IDs are more appropiate (and, in fact,
there are ATTR_SYNCHRONIZED/ATTR_PERSISTENT for IDs). But in
general, values contained in MutableVals are not bound to any ID.
Therefore, these attributes don't help for Vals.
Does this answer your question?
right now I'm mass-murdering Bros whenever I send them
Robin
Hi Robin,
> Okay it's much clearer now, thanks! I guess what's still confusing me is
> why is this happening at the MutableVal level and not in Vals directly?Basically it's just an optimization. We could just as well assign
global names to all values -- but we don't need to. A global name is
only required when a Val can actually be changed. If it can't, it
Do you mean "can be changed" as opposed to "be replaced by a new val"?
will never be referenced by one of the operations transfered during
synchronization (for example, an assignment to an integer always
creates a new Val and destroys the old one).
So when a field's value in a mutable val changes, it's the mutable val
that is flagged as changed and not that individual val -- is that it?
Optimizing even further, we need only assign global names to MutableVals
which are actually synchronized (or, in the future, persistent).
I think that's what's confusing me. A better way to put my question is
probably: if I want a val to be synchronized/persistent, it seems it has
to be a mutable val (i.e., a table/set or a record). Right?
> I think this also comes back to the properties in MutableVals that I
> don't quite understand -- why are these not attributes?Which kind of attributes are you refering to? (The term "attribute"
is quite is overloaded in Bro...). The attributes which are
associated with Vals are RecordVals which don't really fit here
(frankly, right now I can't remember what they are for... :-). The
attributes associated with IDs are more appropiate (and, in fact,
there are ATTR_SYNCHRONIZED/ATTR_PERSISTENT for IDs). But in
general, values contained in MutableVals are not bound to any ID.
Therefore, these attributes don't help for Vals.
Ah right! I meant the ones associated with vals, but I didn't think of
the val/id difference in context of the serialization. Thanks!
Cheers,
Christian.