Proto for Boost mailing list page: Re: [proto] proto-11 progress report

Subject: Re: [proto] proto-11 progress report
From: Eric Niebler (eric_at_[hidden])
Date: 2012-07-21 02:18:44

On 7/17/2012 6:14 PM, Eric Niebler wrote:
> I'm considering adding the slots mechanism to proto-current so that this
> can be made to work there, also. The problem is that once you use a
> slot, the data parameter is no longer just a dumb blob. I can make
> proto::_data ignore the slots and just return the dumb blob as before,
> and that will satisfy some. But any custom primitive transforms that
> folks have written will need to be ready for the fact that they could
> get passed something different than what they were expecting. I don't
> think it will break code until you decide to use a slot (or use a
> transform that uses a slot). Then you'll need to fix up your transforms.
> 
> Does anybody object to the above scheme?

This is now implemented on trunk. It's implemented in a backward
compatible way.[*]

What this means is that instead of a monolithic blob of data, the third
parameter to a Proto transforms can be a structured object with O(1)
lookup based on tag. You define a tag with:

  BOOST_PROTO_DEFINE_ENV_VAR(my_tag_type, my_key);

Then, you can use it like this:

  some_transform()(expr, state, (my_key= 42, your_key= "hello"));

In your transforms, you can access the value associated with a
particular key using the proto::_env_var<my_tag_type> transform.

You can still pass an unstructured blob, and things work as they did
before. The proto::_data transform checks to see if the data parameter
is a blob or structured. If it's a blob, that simply gets returned. If
it's structured, it returns the value associated with the
proto::data_type tag. In other words, these two are treated the same:

  int i = 42;
  some_transform()(expr, state, i);
  some_transform()(expr, state, (proto::data= i));

There's more, but I'll save it. It's a big change, and docs are yet to
be written. Y'all might want to test your code against trunk and report
problems early. (This will *not* be part of 1.51.)

[*] I had to make some changes to Phoenix though because unfortunately
Phoenix makes use of some undocumented parts of Proto.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com