Re: [boost] [system] system-0.2 request for comments

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-07-24 21:23:07

"David Bergman" <davidb_at_[hidden]> wrote in message 
news:005301c6aeb6$576d2750$a0da1105_at_davidtp...
> Beman wrote:
>
>> * Addition of a header boost/identifier.hpp. For years I've
>> used a similar class to provide the type safety and freedom
>> from unwanted conversions that is missing when a simple int
>> is used for an identifier.
>> This is logically separate from the system stuff, but for
>> convenience is included in the system package since
>> error_code.hpp uses it.
>
> I like the idea of having such a (meta) construct in my programming
> portfolio, much like the "newtype" in Haskell, which introduces an
> isomorphic type.
>
> A few comments:
>
> 1. You are right in that it is separate, and should definitely be separate
> from the error code stuff; actually, since it is a construct mapping types
> to types - i.e., a meta function - it might even find its proper home in 
> MPL
> :-)

Yes - I just included it with the error code stuff because it was needed 
there, and I wanted to see if there was any interest in it as a separate 
submission.

> 2. As someone else pointed out, even though this functor establishing
> homorphic types is useful for the use case of having identifiers, it 
> should
> not stop there. Thus, its name should reflect that wider scope, such as
> "homorphic_type." Ok, more pragmatic then: "embed_type." [hope that going
> from a adjective to a verb did not tick anyone off]
>
> 3. I see a few distinct types of homomorphisms here, which should 
> correspond
> to policies:
> (i)   order
> (ii)  equivalence
> (iii) assignability
> (iv)  conversion (to source)
>
>   I implemented them as individual policy links that are then chained
> together explicitly. Will use a hierarchy generator, such as Loki's, or
> create a
> chaining construct with the help of MPL and upload it to the vault.

I toyed with the idea of either a policy-base or generative-programming 
approach, and decided they would add a lot of complexity for very little 
gain when compared to just telling the user to code the members, which are 
very simple, when needed. Simplicty has its virtues.

That said, I encourage you to keep refining your ideas. You may be able to 
craft a homomorphic type generater that has enough benefits to be 
compelling.

--Beman