[Bro] About IDs in MutableVals

Christian Kreibich christian at whoop.org
Fri Dec 3 07:49:15 PST 2004

On Fri, 2004-12-03 at 15:16, Robin Sommer wrote:
> On Fri, Dec 03, 2004 at 14:27 +0000, Christian Kreibich wrote:
> > Why is this global namespacing done?
> 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).

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


More information about the Bro mailing list