Interest in specialized types
Hello, in http://permalink.gmane.org/gmane.comp.lib.boost.devel/207794 Robert Ramey talked about wrapping some POD to increase type safety. Some time ago I used something similar to ensure that misuse of values can be found by the compiler. 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. Regards Henning
Henning Basold wrote :
Robert Ramey talked about wrapping some POD to increase type safety. Some time ago I used something similar to ensure that misuse of values can be found by the compiler.
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). [...] Do you think this might be a useful utility? Or is there something similar already available? [...]
Personnaly, I simply use a strongtypedef macro. A good news is that there is already one done in serialization : strong_typedef.hpp (maybe this one could have gone into boost.utility?). I think you have got something to dig, even if I am not convinced that I would use your interface in a real project over the already existing strong_typedef. Could you give some real world cunny examples of use? Best regards, Pierre Morcello
Am 22.08.2010 18:29, schrieb Pierre Morcello:
Henning Basold wrote :
Robert Ramey talked about wrapping some POD to increase type safety. Some time ago I used something similar to ensure that misuse of values can be found by the compiler.
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). [...] Do you think this might be a useful utility? Or is there something similar already available? [...] Personnaly, I simply use a strongtypedef macro. A good news is that there is already one done in serialization : strong_typedef.hpp (maybe this one could have gone into boost.utility?).
I think you have got something to dig, even if I am not convinced that I would use your interface in a real project over the already existing strong_typedef. Could you give some real world cunny examples of use?
Best regards,
Pierre Morcello
_______________________________________________ Unsubscribe& other changes:http://lists.boost.org/mailman/listinfo.cgi/boost
Hi, now that you mention it I'm remembering the existence of strong_typedef. The main use case I had in mind were ID objects that are generated to identify objects somewhere. I used them to decouple references to objects from the containers and to easily serialize them. To find more interesting examples I have to think a bit :) Regards Henning
Pierre Morcello wrote:
Henning Basold wrote :
Robert Ramey talked about wrapping some POD to increase type safety. Some time ago I used something similar to ensure that misuse of values can be found by the compiler.
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). [...] Do you think this might be a useful utility? Or is there something similar already available? [...]
Personnaly, I simply use a strongtypedef macro. A good news is that there is already one done in serialization : strong_typedef.hpp (maybe this one could have gone into boost.utility?).
I think you have got something to dig, even if I am not convinced that I would use your interface in a real project over the already existing strong_typedef. Could you give some real world cunny examples of use?
I see this proposal as quite different from strong_typedef (and by implication opaque which I think is a better implementation of strong_typedef). When I say strong_typedef here I'm referring to BOOST_SERIALIZATION_STRONG_TYPEDEF. strong_typedef is just a way to assign a type to an integer or other POD type. It inherits all the operators and is free convertible to the underlying type. It's useful for template meta-programming where one wants to dispatch to code depending on the the type. In effect, it creates a compile time pair <specialized_type, POD> which acts just like the POD but is distinguishable. One use case for this is the serialization library which permits one to have different code to handle special types which are in fact integers and permit them to be trapped and handled specially without accidently invoking the serialization code for the original POD through the whole program. This proposal is quite different. Rather than inheriting all the behavior of the underlying POD, it's purpose is to restrict it - thereby trapping non-sensical operations at compile time. I do see the value in generalizing this - bascally to avoid rookie mistakes like leaving out the assignment operartor (which C++ "helpfully" sticks in for me). So I think this idea DOES have merit. I looked a little at your implementation and I think it's very, very cool. This is going to start a whole new thread. Here are the things that come to my mind. a) The implementation isn't really enough for me to visualize how easy and useful it would be to use. I realize that making a document with tutorial and examples is a bigger effort, but I for one would encourage you to invest this effort. b) When I see a concept "Additive" I'm thinking uh-oh, this is going to spin a whole lot of new stuff. Here is what goes on in my brain. Additive - hmmm why not multiplicative Additive/multiplicative - why not step back to set element - no operations except equality group element - additive operators + null element different types of groups? field element - additive + multiplacative + ... Which to me is a facinating direction. I believe that there have been proposals for C++ libraries to manage these kind of types. And of course there is the unit's library which touchs this area. Sooooooooo - maybe you want to drop "additive" or maybe not. Anyway, I would encourage you to spend more effort in this. I was using strong_typedef and it was fine for my purposes. But I moved to the "restricted" typedef to elminate warnings and trap bugs. So there is definitely a use for such a thing. I see this idea as one of those few which can be a library small enough to actually do, be easy and useful to use. There aren't many opportunities like this these days. Good luck with this. Robert Ramey
Am 22.08.2010 21:22, schrieb Robert Ramey:
Pierre Morcello wrote:
Henning Basold wrote :
Robert Ramey talked about wrapping some POD to increase type safety. Some time ago I used something similar to ensure that misuse of values can be found by the compiler.
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). [...] Do you think this might be a useful utility? Or is there something similar already available? [...] Personnaly, I simply use a strongtypedef macro. A good news is that there is already one done in serialization : strong_typedef.hpp (maybe this one could have gone into boost.utility?).
I think you have got something to dig, even if I am not convinced that I would use your interface in a real project over the already existing strong_typedef. Could you give some real world cunny examples of use? I see this proposal as quite different from strong_typedef (and by implication opaque which I think is a better implementation of strong_typedef). When I say strong_typedef here I'm referring to BOOST_SERIALIZATION_STRONG_TYPEDEF.
strong_typedef is just a way to assign a type to an integer or other POD type. It inherits all the operators and is free convertible to the underlying type. It's useful for template meta-programming where one wants to dispatch to code depending on the the type. In effect, it creates a compile time pair<specialized_type, POD> which acts just like the POD but is distinguishable. One use case for this is the serialization library which permits one to have different code to handle special types which are in fact integers and permit them to be trapped and handled specially without accidently invoking the serialization code for the original POD through the whole program.
This proposal is quite different. Rather than inheriting all the behavior of the underlying POD, it's purpose is to restrict it - thereby trapping non-sensical operations at compile time. I do see the value in generalizing this - bascally to avoid rookie mistakes like leaving out the assignment operartor (which C++ "helpfully" sticks in for me). So I think this idea DOES have merit.
I looked a little at your implementation and I think it's very, very cool.
This is going to start a whole new thread. Here are the things that come to my mind.
a) The implementation isn't really enough for me to visualize how easy and useful it would be to use. I realize that making a document with tutorial and examples is a bigger effort, but I for one would encourage you to invest this effort.
b) When I see a concept "Additive" I'm thinking uh-oh, this is going to spin a whole lot of new stuff. Here is what goes on in my brain.
Additive - hmmm why not multiplicative Additive/multiplicative - why not step back to
set element - no operations except equality group element - additive operators + null element different types of groups? field element - additive + multiplacative + ...
Which to me is a facinating direction. I believe that there have been proposals for C++ libraries to manage these kind of types. And of course there is the unit's library which touchs this area.
Sooooooooo - maybe you want to drop "additive" or maybe not.
Anyway, I would encourage you to spend more effort in this. I was using strong_typedef and it was fine for my purposes. But I moved to the "restricted" typedef to elminate warnings and trap bugs. So there is definitely a use for such a thing.
I see this idea as one of those few which can be a library small enough to actually do, be easy and useful to use. There aren't many opportunities like this these days.
Good luck with this.
Robert Ramey
_______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Hi,
thank you very much for your feedback. First: yes, permitting operations that don't make sense was my intention. The reason was that I'm a student and work in a company in parallel and was refactoring some software. That software has to be easily maintainable after I'm gone. There a strict type system helps a lot (beside design documents etc. :) ). You may not believe it, but while adding "Additive" I had the same thoughts. "Multiplicative" is already there but I left it out to minimize the code and show only the relevant stuff. While adding these concepts I thought about groups and rings etc., too. But the question is if it is needed. It might be useful to specify algorithms (e.g. associativity for folding). This also falls into the scope of concepts and their axioms which unfortunately have been dropped. Side note: concept maps may be thought of as the reverse of the restriction that NewType imposes. The implementation of a new concept that a type may be restricted to is very simple so one may provide only a small base which a user can easily extend. A rather contrived example here is to restrict a deque to a stack or a queue. You are right that the current state does not really show good applications. I will think and come back with some (hopefully good) examples. Maybe someone already has one. I would be happy to hear about them. Best Regards Henning PS: some credit for the implementation goes to Alexandresu's "Scattered Hierarchy" from "Modern C++ Design".
On 23/08/10 08:49, Henning Basold wrote:
You are right that the current state does not really show good applications. I will think and come back with some (hopefully good) examples. Maybe someone already has one. I would be happy to hear about them.
I often use an 'identifier' integer-wrapper which supports incrementing (pre- and post-), equality-comparison, conversion to and from string, and serialization (and conversion to and from the underlying integers for when you really have to). In particular I'd encourage you to support serialization if you hadn't thought of that yet. John Bytheway
----- Original Message ----- From: "Henning Basold" <h.basold@googlemail.com> To: <boost@lists.boost.org> Sent: Sunday, August 22, 2010 5:49 PM Subject: [boost] Interest in specialized types
Hello,
in http://permalink.gmane.org/gmane.comp.lib.boost.devel/207794 Robert Ramey talked about wrapping some POD to increase type safety. Some time ago I used something similar to ensure that misuse of values can be found by the compiler.
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.
Hi, I'm currently working on Boost.Opaque http://svn.boost.org/svn/boost/sandbox/opaque/ (Not yet on the Vault) which tries to implement strong typedefs for fundamental types. It is based on "Progress toward Opaque Typedefs for C++0X" http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf which was not accepted for inclusion on C++0x. // Cartesian 3D coordinate types BOOST_OPAQUE_PUBLIC_TYPEDEF(double, X); BOOST_OPAQUE_PUBLIC_TYPEDEF(double, Y); BOOST_OPAQUE_PUBLIC_TYPEDEF(double, Z); // polar 3D coordinate types BOOST_OPAQUE_PUBLIC_TYPEDEF(double, Rho); BOOST_OPAQUE_PUBLIC_TYPEDEF(double, Theta); BOOST_OPAQUE_PUBLIC_TYPEDEF(double, Phi); class PhysicsVector { public: PhysicsVector(X, Y, Z); PhysicsVector(Rho, Theta, Phi); ... }; // PhysicsVector 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. Best, Vicente
Am 22.08.2010 19:22, schrieb vicente.botet:
----- Original Message ----- From: "Henning Basold"<h.basold@googlemail.com> To:<boost@lists.boost.org> Sent: Sunday, August 22, 2010 5:49 PM Subject: [boost] Interest in specialized types
Hello,
in http://permalink.gmane.org/gmane.comp.lib.boost.devel/207794 Robert Ramey talked about wrapping some POD to increase type safety. Some time ago I used something similar to ensure that misuse of values can be found by the compiler.
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. Hi,
I'm currently working on Boost.Opaque http://svn.boost.org/svn/boost/sandbox/opaque/ (Not yet on the Vault) which tries to implement strong typedefs for fundamental types. It is based on "Progress toward Opaque Typedefs for C++0X" http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf which was not accepted for inclusion on C++0x.
// Cartesian 3D coordinate types BOOST_OPAQUE_PUBLIC_TYPEDEF(double, X); BOOST_OPAQUE_PUBLIC_TYPEDEF(double, Y); BOOST_OPAQUE_PUBLIC_TYPEDEF(double, Z);
// polar 3D coordinate types BOOST_OPAQUE_PUBLIC_TYPEDEF(double, Rho); BOOST_OPAQUE_PUBLIC_TYPEDEF(double, Theta); BOOST_OPAQUE_PUBLIC_TYPEDEF(double, Phi);
class PhysicsVector { public: PhysicsVector(X, Y, Z); PhysicsVector(Rho, Theta, Phi); ... }; // PhysicsVector
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.
Best, Vicente
_______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Hi,
that's very interesting. Especially the interface to test for relation of types. 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. I used the restriction for automatically generated ID objects (see answer to Pierre's post). Regards Henning
----- Original Message ----- From: "Henning Basold" <h.basold@googlemail.com> To: <boost@lists.boost.org> 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@googlemail.com> To:<boost@lists.boost.org> 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
Am 24.09.2010 12:31, schrieb vicente.botet:
----- Original Message ----- From: "Henning Basold"<h.basold@googlemail.com> To:<boost@lists.boost.org> 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@googlemail.com> To:<boost@lists.boost.org> 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.
----- Original Message ----- From: "Henning Basold" <h.basold@googlemail.com> To: <boost@lists.boost.org> Sent: Monday, September 27, 2010 3:26 PM Subject: Re: [boost] Interest in specialized types
Am 24.09.2010 12:31, schrieb vicente.botet:
Before refactoring the Opaque implementation, I wanted to know if you have worked on your proposal.
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.
Yes, I have integrated your ideas into Opaque after posting this message. Your approach allows to define opaque types fpr underlying UDT :) I hope both approaches are now well integrated. I have reached to implement a transitive conversion, either implicit for public opaque type or explicit for private opaque types. I gues these kind of transitive conversion could also be used for new_types that are more restrictive than opaque types.
PS: The concept could for example be used to implement a generalized type erasure which could be used in a type safe manner.
I don't understand completly. Could you explain a little more? Thanks, Vicente
2010/9/27 vicente.botet <vicente.botet@wanadoo.fr>:
----- Original Message ----- From: "Henning Basold" <h.basold@googlemail.com> To: <boost@lists.boost.org> Sent: Monday, September 27, 2010 3:26 PM Subject: Re: [boost] Interest in specialized types
Am 24.09.2010 12:31, schrieb vicente.botet:
Before refactoring the Opaque implementation, I wanted to know if you have worked on your proposal.
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.
Yes, I have integrated your ideas into Opaque after posting this message. Your approach allows to define opaque types fpr underlying UDT :) I hope both approaches are now well integrated.
I have reached to implement a transitive conversion, either implicit for public opaque type or explicit for private opaque types. I gues these kind of transitive conversion could also be used for new_types that are more restrictive than opaque types.
Sounds good. Hopefully you can propose it soon for inclusion so I can use it in production code :)
PS: The concept could for example be used to implement a generalized type erasure which could be used in a type safe manner.
I don't understand completly. Could you explain a little more?
The idea is very similar to Boost.Function. That is you have a fixed interface that one can use on arbitrary types. The concret type is then hidden after construction. The only difference to Boost.Function is that you can specify an arbitrary interface and not just function calls. The interace specification is done analogously to new_type. So one could use Boost.Any without having to know the concret type which is stored inside (as long as the object itself isn't needed). My only problem so far is that I haven't found a way that objects do no grow in size or the dispatching in time with the number of possible methods.
Thanks, Vicente _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Regards, Henning
participants (5)
-
Henning Basold -
John Bytheway -
Pierre Morcello -
Robert Ramey -
vicente.botet