Re: [boost] Interest in specialized types

Subject: Re: [boost] Interest in specialized types
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-09-24 06:31:14

----- Original Message ----- 
From: "Henning Basold" <h.basold_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, August 22, 2010 8:37 PM
Subject: Re: [boost] Interest in specialized types

> 
>  Am 22.08.2010 19:22, schrieb vicente.botet:
>> ----- Original Message -----
>> From: "Henning Basold"<h.basold_at_[hidden]>
>> To:<boost_at_[hidden]>
>> Sent: Sunday, August 22, 2010 5:49 PM
>> Subject: [boost] Interest in specialized types
>>
>>
>>> So I think that is something that can be generalized. The concept is to
>>> wrap a type into a class and restrict the interface. This ensures that
>>> values from one context (e.g. an id) can't be used in another context
>>> (e.g. adding of number or as an id for other objects).
>>>
>>> Attached is a very simple implementation where the needed concepts can
>>> be specified as parameter. To distinguish for example between different
>>> id types also a tag type can be specified.
>>>
>>> Do you think this might be a useful utility? Or is there something
>>> similar already available? I've searched the vault but did not find
>>> anything.

>> The approach I have taken doesn't allows, as yours, to restrict the interface but just to allow or not  the implicit conversion between the opaque/strong-typed type and the underlying type.
>>
>> I recognize that the ability to restrict the interface is more general, but I'll need some concrete use cases for which restricting the interface is absolutlely needed.
> 
> The idea to the interface came from the Haskell type system. There one 
> can define new types and put into a type class. Those type classes 
> implement some functionality such as ordering. This restricts the usable 
> interface to the minimum without relying on automatic conversion.

Hi,

I have think a little bit more about your approach, and the possibility to restrict the interface, can even be used to manage with UDT. The Opaque approach I implemented don't allows to do that as the interface in inherited implicitly for the builting operations, so there is no possibility to use UDT functions accesible with the dot notation. With the posibility to add as many layes as you want, the user can provide specific layers that provide specific functionalities.

Before refactoring the Opaque implementation, I wanted to know if you have worked on your proposal.

Best,
Vicente