# Proposing a new type: opaque **URL:** \ **Category:** Development\ **Tags:** development\ **Created:** [November 19, 2012, 3:26am UTC](https://community.zeek.org/t/proposing-a-new-type-opaque/2494 "2012-11-19T03:26:59Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Matthias\_Vallentin1](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/matthias_vallentin1/32/596_2.png) [@Matthias\_Vallentin1](https://community.zeek.org/u/Matthias_Vallentin1)\ **Post date:** [November 19, 2012, 3:26am UTC](https://community.zeek.org/t/proposing-a-new-type-opaque/2494/1 "2012-11-19T03:26:59Z")
Bro currently misuses the any type to describe "handle" or "descriptor" types. Consider for example the MD5 function family, which take a state object as first argument. At the scripting layer, it has no other purpose than mapping to the corresponding MD5 state at the core. Users don't use it otherwise. There exists no dedicated handle type in Bro, although it wouldn't be complicated to add one. I am encountering this during the review of Soumya's cardinality counter code. Before continuing with the merge, I propose to add a dedicated opaque type that has the form:     opaque of T where T is an identifier from the parsers perspective. For example, this would entail a signature change from     md5\_hash\_init(idx: any): bool to     md5\_hash\_init(idx: opaque of MD5): bool At script load time, Bro can ensure type safety by performing string comparisons that come with the identifier. Such a type would finally add structure to the process of adding new BiFs and related extensions.    Matthias ---
**Author:** ![Seth\_Hall3](https://avatars.discourse-cdn.com/v4/letter/s/d6d6ee/32.png) [@Seth\_Hall3](https://community.zeek.org/u/Seth_Hall3)\ **Post date:** [November 19, 2012, 3:30pm UTC](https://community.zeek.org/t/proposing-a-new-type-opaque/2494/2 "2012-11-19T15:30:32Z")
> There exists no dedicated handle type in Bro, > although it wouldn't be complicated to add one. Yes, having a handle type in Bro would be incredibly handy. > I am encountering this during the review of Soumya's cardinality counter > code. Before continuing with the merge, I propose to add a dedicated > opaque type that has the form: > >    opaque of T Not sure I like this. It seems too similar to the current syntax of tables and vectors (I do want to see the vector syntax eventually though). It looks like T would be a yield value. In the spirit of keeping the discussion going I'll try and propose an alternate syntax. 🙂 >    md5\_hash\_init(idx: opaque of MD5): bool opaque\ I'm not sure I like this either because it would be adding new tokens to the parser, but it is a pretty new concept to add to Bro too.   .Seth ---
**Author:** ![Matthias\_Vallentin1](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/matthias_vallentin1/32/596_2.png) [@Matthias\_Vallentin1](https://community.zeek.org/u/Matthias_Vallentin1)\ **Post date:** [November 19, 2012, 4:57pm UTC](https://community.zeek.org/t/proposing-a-new-type-opaque/2494/3 "2012-11-19T16:57:51Z")
> \> opaque of T > > Not sure I like this. It seems too similar to the current syntax of > tables and vectors (I do want to see the vector syntax eventually > though). It looks like T would be a yield value. I see the similarity to other language elements rather as a consistent form of integration. Why would the "T of Y" syntax only pertain to container types? Admittedly, we have currently no other uses, but looks like a reasonable one to me. > opaque\ While this looks good to folks familiar with C++ and templates, it looks like an exceptional one-off to the Bro language. As you said, it would involve tweaking both lexer and parser, and when is a about to happen, we should rethink the added value.    Matthias ---
**Author:** ![Vern](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/vern/32/630_2.png) [@Vern](https://community.zeek.org/u/Vern)\ **Post date:** [November 28, 2012, 6:03am UTC](https://community.zeek.org/t/proposing-a-new-type-opaque/2494/4 "2012-11-28T06:03:14Z")
> \> ... It looks like T would be a yield value. > > I see the similarity to other language elements rather as a consistent > form of integration. Why would the "T of Y" syntax only pertain to > container types? Admittedly, we have currently no other uses, but looks > like a reasonable one to me. > > \> opaque\ > > While this looks good to folks familiar with C++ and templates, it looks > like an exceptional one-off to the Bro language. As you said, it would > involve tweaking both lexer and parser, and when is a about to happen, > we should rethink the added value. Yeah, I agree with Matthias here on both of these points. "opaque of T" strikes me as reasonable syntax.     Vern ---
**Author:** ![Seth\_Hall3](https://avatars.discourse-cdn.com/v4/letter/s/d6d6ee/32.png) [@Seth\_Hall3](https://community.zeek.org/u/Seth_Hall3)\ **Post date:** [November 28, 2012, 2:47pm UTC](https://community.zeek.org/t/proposing-a-new-type-opaque/2494/5 "2012-11-28T14:47:21Z")
Works for me then.   .Seth ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\ **Post date:** [May 6, 2022, 3:40pm UTC](https://community.zeek.org/t/proposing-a-new-type-opaque/2494/6 "2022-05-06T15:40:40Z")