Re: [boost] Interest in specialized types

Subject: Re: [boost] Interest in specialized types
From: Henning Basold (h.basold_at_[hidden])
Date: 2010-09-27 09:26:40

  Am 24.09.2010 12:31, schrieb vicente.botet:
> ----- 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
>
>
> _______________________________________________
> Unsubscribe&  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi,

I am sorry to say but I haven't. I'm in the middle of writing my 
bachelor thesis so I don't have a lot of time right now. But my brains 
works despite the body has no time :) So I have some ideas for use cases 
but no time to write them down.

I see you have already integrated the idea into Opaque. So the basics 
are already there. Are you satisfied with it and is there anything to do 
in this area. Else I would use my time (if I should have some ;)) on 
extending the idea.

Regards
Henning

PS: The concept could for example be used to implement a generalized 
type erasure which could be used in a type safe manner.