Re: [boost] Interest in a 'Boost.property' library?
Personally, I always consider properties with getters/setters an anti-pattern for OOP languages like C++. Class interfaces should include only those methods that describe logically valid actions one might take on instances of the class. The idea of properties might sometimes be appropriate. But often times, programs will see a hammer and treat everything they see after it as nails. It becomes easy to add a few more getters and setters for "the rest" of the implementation details and you lose proper encapsulation. Usually when I find a class with lots of get/set methods I find a class with very little thought used when that class was designed.
On 8 July 2013 05:31, Joe Mucchiello
Personally, I always consider properties with getters/setters an anti-pattern for OOP languages like C++.
C++ is not an OOP, but multiparadigm language. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
This is surely a controversial feature. I see some use of properties, like allowing to add checks on setting values to a type which was a simple struct initially (which happen a lot in data-centric designs). Also it can make things clear that the provided function is really an accessor and nothing more (like the = operator which should do nothing more than a copy or move). I'm not against properties, I see some cases where they might be useful, however I don't like all the non-native solutions proposed with C++. The main reason is that these solutions adds a lot of noise for not much. Joel Lamotte
08.07.2013 12:33, Klaim - Joël Lamotte:
This is surely a controversial feature. I see some use of properties, like allowing to add checks on setting values to a type which was a simple struct initially (which happen a lot in data-centric designs).
If check does not need any internals of enveloping object, or does not need to be overridable by enveloping class descendants - which is often the case - then in C++ - it should be done just like normal concrete class, with invariants established in constructors. -- Evgeny Panasyuk
On Mon, Jul 8, 2013 at 11:19 AM, Evgeny Panasyuk
08.07.2013 12:33, Klaim - Joël Lamotte:
This is surely a controversial feature.
I see some use of properties, like allowing to add checks on setting values to a type which was a simple struct initially (which happen a lot in data-centric designs).
If check does not need any internals of enveloping object, or does not need to be overridable by enveloping class descendants - which is often the case - then in C++ - it should be done just like normal concrete class, with invariants established in constructors.
That is not at all the point I was making, my point is that code evolve. While it's ok to have naked struct in some data-centric designs, sometimes, after use, you might realize that some of these struct still need some kind of checks on access (or on copy or in some other conditions) which just help getting correct data. IF you happen to be in this specific case where you have that naked struct that needs to be enhanced with access checks because of evolution of design, THEN changing access to member functions often imply a lot of changes in the code base while it's only the internal semantic of the type that you need to change, not the actual interface. I've found this case maybe 2 or 3 times in the last 10 years while working on very big code bases and I know it can make you loose time in days, so most of the time you want to avoid it in the first place and learn to use memver function only. But then the role of function member when you see it in code is to imply processing, while the role of property is to imply transparent checks followed by access or modification of a specific object. So having a specific interface to clarify the difference and in the same time make the code easy to change is to me a win. Not a big win but a win nonetheless. That being clarified, for me it's a minor feature for language design, with weak priority, but I still see some interesting use. It's kind of like all these C++ features you use maybe once every pair of years but makes you express your intent exactly and help doing things fast. It's not as important as features you use everyday, but it would be interesting nontheless. Now as I was saying, I don't see the point in a library version of it. If I remember correctly, works on Reflection for C++ points to a way to implement properties as a library construct but it would require Reflection obviously. Joel Lamotte
08.07.2013 19:41, Klaim - Joël Lamotte:
I see some use of properties, like allowing to add checks on setting values to a type which was a simple struct initially (which happen a lot in data-centric designs).
If check does not need any internals of enveloping object, or does not need to be overridable by enveloping class descendants - which is often the case - then in C++ - it should be done just like normal concrete class, with invariants established in constructors.
That is not at all the point I was making, my point is that code evolve. While it's ok to have naked struct in some data-centric designs, sometimes, after use, you might realize that some of these struct still need some kind of checks on access (or on copy or in some other conditions) which just help getting correct data. IF you happen to be in this specific case where you have that naked struct that needs to be enhanced with access checks because of evolution of design, THEN changing access to member functions often imply a lot of changes in the code base while it's only the internal semantic of the type that you need to change, not the actual interface.
IF all that you need is to move from basic data types to something with checks, while keeping same syntax THEN properties (as well as getters and setters) are not needed at all - just use concrete classes with invariants established by constructors: http://ideone.com/frui7Z - this example doesn't have any properties-like stuff, while it have checks in second case and same syntax. I think need for properties-like things may arise IFF: "property"'s set/get need access to enveloping object or set/get should be overridable by enveloping class descendants, while keeping same syntax. -- Evgeny Panasyuk
On Mon, Jul 8, 2013 at 6:49 PM, Evgeny Panasyuk
I think need for properties-like things may arise IFF: "property"'s set/get need access to enveloping object or set/get should be overridable by enveloping class descendants, while keeping same syntax.
Which actually happen a lot, like when you want to have vectors and strings in that data. I'm not talking about low-level data that needs to be all in the struct. Anyway, there is no current C++ solution equivalent to the short-and-expressive way to do properties in other languages. You can find tons of ways to do something similar, they are all flawed because not generic enough and often hard to read (like your example, where the semantic of the type is separated from the use which is a bit like declaring manually callable objects when you could have lambdas). Anyway, the point is not that it could be done the same in the language, it can't. Whatever the implementation, the point is that the idea is useful sometimes. So it's worth having a solution for it, but I don't believe in a non-language feature for it or not relying on Reflection. Joel Lamotte
08.07.2013 21:32, Klaim - Joël Lamotte:
I think need for properties-like things may arise IFF: "property"'s set/get need access to enveloping object or set/get should be overridable by enveloping class descendants, while keeping same syntax.
Which actually happen a lot,
Well, maybe. As I said - it is possible that there are some application domains where they are needed frequently.
like when you want to have vectors and strings in that data.
It is interesting to see such examples. If there will be property library in Boost - motivation examples are needed in any case.
So it's worth having a solution for it, but I don't believe in a non-language feature for it or not relying on Reflection.
I agree, some library-based solution would not hurt, but again - it should be mature and provide convenient/concise interface. -- Evgeny Panasyuk
participants (4)
-
Evgeny Panasyuk -
Joe Mucchiello -
Klaim - Joël Lamotte -
Mateusz Loskot