The changing landscape of OOP (from class to struct)
-
Any time man. The longer you're in the industry, the more you see these patterns emerge over and over and over. Here's another example, in the 90s when MS started pushing XML like crazy. Average coders were all like "omg clear text file formats". But, a decade prior we had SGML that did the same exact thing. SGML also required a DTD. Sure, XML was more strict... but it was nothing new in concept. And all these kiddies came along acting like they cured cancer because binary file formats was baaaaaaaad. Even made its way to the web. XML this. XML that. But it was nothing new. Fortunately, the web eventually said screw that... it's bloated. Now JSON is the defacto non-official standard in the web world, and we use conventions rather than a DTD. But the point is, if you used SGML for your typical file format in the 80s... I guarantee you coders would've came along saying how stupid that is.
Jeremy Falcon
The SGML v XML discussion is a perfect example of it, for sure. And speaking of JSON -- the detractors for JSON want this new, new, new THING!! (RUST uses it) It's called TOML (Tom's Obvious, Minimal Language[^]). TOML is so amazing!! It's so new. It's never been seen before!!!! Squeeeeee!! Oh, wait, Windows 3.1 Ini files[^] used that same format. 😅😆🤣🤓
-
raddevus wrote:
Anyways, what do you think about this "Primitive Obsession code smell"?
It seems like the book author is someone trying to sound smarter than they are. Just because someone writes a book doesn't make them a genius. Now, I do agree that primitive obsession is bad, but so is struct obsession. A struct won't inherently prevent a coder from mistaking milliseconds for seconds (to borrow from this thread's example). But, what it does do is offer more complexity in an application that may otherwise not be needed. A lot of these "new" ideas are just rehashed old ideas from JavaScript. I'm dead serious. It's just people looking for something to do rather than go outside. In JavaScript, some folks love to use an object as a parameter for everything. It's the loose and fast version of a struct in C#. It's just as ridiculous to expect an object as a single param in every last routine. The problem is, the obsession or abuse of any one concept. Average coders take one little thing and run with it because it's the new shiny doodad. Abusing structs is no better. It's just change for change's sake while pretending to be smart. It's about balance.
raddevus wrote:
Step 4 Is Immutability
To the point of the book, to make each struct read only is a good idea. But, to the point of "prefer composition over inheritance", both Java and C# were literally designed with an OOP paradigm in mind. Move to a functional language if you want to start acting functional. In regard to immutability, you can use a sealed class in Java and C# as well. The irony is, all this struct talk is reminding me of C. People always said C sucked because it doesn't support classes. And yet, here we are. People just following the hype train because people looking to change something for no real gain and refuse to go outside. And I say this as a dude who loves functional programming, C# wasn't designed that way.
Jeremy Falcon
Jeremy Falcon wrote:
The irony is, all this struct talk is reminding me of C.
In my first University level programming class, Pascal was the programming language. We were taught a programming discipline where all attributes relating to a phenomenon (such as a physical object) where put together in a struct. All manipulation of variables of a given struct type were done by a set of functions and procedures (those are the Pascal terms) declared together with the struct type definition. All functions / procedures should take a pointer to a struct as its first argument. The course included creating general struct types, and including these in more specialized substruct types adding more attributes. It also included handling polymorphic types, using the variant structure facility of Pascal. I took this first course in object oriented use of Pascal structs (no, we didn't label it as such!) in the fall of 1977. When OO arrived (C++ in 1985), we moved the first argument - the struct pointer - to make a prefix to the function / procedure name, with a separating dot. The biggest change was the OO term, and starting to say 'method' rather than function / procedure. Sub/superclasses, polymorphism and a general OO mindset had been in place for several years; we just didn't know it by that name. So quite fancy use of structs for creating objects / blackboxed types has at least 45 years on its back. Back then, some of it relied on programming discipline, not compiler support - but use of structs to create distinct types, as the book author suggests, doesn't really have any compiler support at the concept level, either.
-
Any time man. The longer you're in the industry, the more you see these patterns emerge over and over and over. Here's another example, in the 90s when MS started pushing XML like crazy. Average coders were all like "omg clear text file formats". But, a decade prior we had SGML that did the same exact thing. SGML also required a DTD. Sure, XML was more strict... but it was nothing new in concept. And all these kiddies came along acting like they cured cancer because binary file formats was baaaaaaaad. Even made its way to the web. XML this. XML that. But it was nothing new. Fortunately, the web eventually said screw that... it's bloated. Now JSON is the defacto non-official standard in the web world, and we use conventions rather than a DTD. But the point is, if you used SGML for your typical file format in the 80s... I guarantee you coders would've came along saying how stupid that is.
Jeremy Falcon
Jeremy Falcon wrote:
in the 90s when MS started pushing XML like crazy.
It most definitely was not limited to MS! I never even expired them as very dominating in the XML rush. It was always the *nix guys who insisted on all information in the system being stored as 7-bit ASCII so any hacker would be able to modify any system data using ed for modifying it. To pick one example: Open Office XML entered the market several years before MS changed from binary formats to OOXML. I never loved XML (and some of the tools even less than the plain XML format, e.g. XSLT). I went to a Digital Library conference around 2002, and for the first twelve presentations I visited, eleven of them made a major issue of their use of XML and all its benefits. Methinks not. But the issue was not up for discussion; it was settled, carved in stone: "XML is good for you! Always!" After XML we went into a period of 'Every decent programmer has his own data description language'. One project I was in - and it wasn't a very big one - used four different description languages, all of which covered the same functionality. If JSON is the one to kick out all the others, it is a step forward, no matter its weaknesses. But it seems like new alternatives keep popping up all the time. Maybe JSON is The Answer this year, but I am fully prepare for it being thrown to the wolves within a couple of years.
-
Jeremy Falcon wrote:
The irony is, all this struct talk is reminding me of C.
In my first University level programming class, Pascal was the programming language. We were taught a programming discipline where all attributes relating to a phenomenon (such as a physical object) where put together in a struct. All manipulation of variables of a given struct type were done by a set of functions and procedures (those are the Pascal terms) declared together with the struct type definition. All functions / procedures should take a pointer to a struct as its first argument. The course included creating general struct types, and including these in more specialized substruct types adding more attributes. It also included handling polymorphic types, using the variant structure facility of Pascal. I took this first course in object oriented use of Pascal structs (no, we didn't label it as such!) in the fall of 1977. When OO arrived (C++ in 1985), we moved the first argument - the struct pointer - to make a prefix to the function / procedure name, with a separating dot. The biggest change was the OO term, and starting to say 'method' rather than function / procedure. Sub/superclasses, polymorphism and a general OO mindset had been in place for several years; we just didn't know it by that name. So quite fancy use of structs for creating objects / blackboxed types has at least 45 years on its back. Back then, some of it relied on programming discipline, not compiler support - but use of structs to create distinct types, as the book author suggests, doesn't really have any compiler support at the concept level, either.
Extremely fascinating story. Thanks for sharing. As I was reading your description...
trønderen wrote:
All manipulation of variables of a given struct type were done by a set of functions and procedures (those are the Pascal terms) declared together with the struct type definition. All functions / procedures should take a pointer to a struct as its first argument.
...I was thinking, that sounds like a class (or just a half-step away) -- data encapsulation with associated functions that work on the data. Very interesting.
trønderen wrote:
Back then, some of it relied on programming discipline, not compiler support
I have talked about this for a long time. 1. If you don't have disciplined devs (engineering mentality of "do the right thing"), then 2. you better have a technology that forces the discipline (example, private vars cannot be manipulated outside class). This is also why old timers (who had to have a disciplined mindset so they didn't cause themselves problems) see a lot of the new stuff as just fluff. Two Thoughts 1. There are people who still create total crap, even with all the tools and automated discipline we have now. 2. There were people in the past who created amazing feats of software, even though all the discipline was required to be inside them.
-
Extremely fascinating story. Thanks for sharing. As I was reading your description...
trønderen wrote:
All manipulation of variables of a given struct type were done by a set of functions and procedures (those are the Pascal terms) declared together with the struct type definition. All functions / procedures should take a pointer to a struct as its first argument.
...I was thinking, that sounds like a class (or just a half-step away) -- data encapsulation with associated functions that work on the data. Very interesting.
trønderen wrote:
Back then, some of it relied on programming discipline, not compiler support
I have talked about this for a long time. 1. If you don't have disciplined devs (engineering mentality of "do the right thing"), then 2. you better have a technology that forces the discipline (example, private vars cannot be manipulated outside class). This is also why old timers (who had to have a disciplined mindset so they didn't cause themselves problems) see a lot of the new stuff as just fluff. Two Thoughts 1. There are people who still create total crap, even with all the tools and automated discipline we have now. 2. There were people in the past who created amazing feats of software, even though all the discipline was required to be inside them.
Quote:
This is also why old timers (who had to have a disciplined mindset so they didn't cause themselves problems) see a lot of the new stuff as just fluff.
I resemble that remark.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
Just started reading this (just released) book, The C# Type System (no starch press)[^] and the first chapter is kind of blowing my mind. Step 1 Author starts out with the following example and says, "You must use better named variables so dev users know what they mean."
Displacement(double t, double v, double s)
{
var x = v * s * Math.Cos(t);
var y = v * s * Math.Sin(t) - 0.5 * 9.81 * Math.Pow(s, 2);
return (x, y);
}Yes, that makes sense. Step 2 Then he says, "Oh, you can add meaning with this new idea of named arguments so users don't have to remember order that they should be passed in."
var result = Displacement(angle: .523, speed: 65, elapsedTime: 4);
Ok, yes, that is good advice with the modern capabilities. Step 3 May Blow Your Mind He mentions that the code is still confusing because all three arguments are the same primitive type (double) and this leads into...
From the book:
Primitive Obsession code smell, which describes any code that has an overreliance on primitive types—that is, those types that are built into the language, such as int, double, and string.
The solution is... Wrap All the Primitive Types In Structs 🤯🤯🤯🤯🤯
public struct Angle
{
public double Size {get; set;}
}
public struct Speed
{
public double Amount {get; set;}
}The Paradigm Has Shifted Now, when the user attempts to call the
Displacementmethod the compiler will know that the argument type is wrong. Now, there's no way to pass the wrong value into the method, because the compiler will know the type. Wow, that is a very different paradigm!! Step 4 Is Immutability Now, make each struct immutableI've been working a lot lately with Spring Webflux/Reactor and they liberally use the
Durationclass for any time specs.//so instead of
long ticks
long ms
long s
//etc, etc, you see
Duration t
//and you create values using stuff like
Duration.ofSeconds
Duration.ofMillisecondsBy not obsessing over primitives, they made it so that all methods that use times can accept any time. You don't have to constantly remind yourself what the context for that time value is (e.g. seconds, milliseconds, etc), because the method doesn't specify the context, you do. So I love the idea of better contextualizing values beyond their strict storage type. As long as there's a useful context that adds value. From your example, I think an
Angleabstraction that handled both radians and degrees could prove useful in a similar manner toDuration, for example. As given, I'm not sure abstracting adoubleto anAnglesolely to remove the primitive is a good pattern though. My assumption is that the intention is to force the developer to explicitly contextualize the double value, but the thing is if the developer didn't care about the context before, they aren't going to care now. They'll just wrap the double they have and move on (e.g.ex.handleAngle(new Angle(someDoubleThatIsntAnAngle))). Elevating a primitive in this way doesn't actually achieve anything that variable naming and/or named arguments couldn't already do. Just having a nondescriptAnglewith adoublesize property does nothing to further describe adouble angleparameter. There has to be more sauce to it to make the abstraction worth it in my opinion. -
I've been working a lot lately with Spring Webflux/Reactor and they liberally use the
Durationclass for any time specs.//so instead of
long ticks
long ms
long s
//etc, etc, you see
Duration t
//and you create values using stuff like
Duration.ofSeconds
Duration.ofMillisecondsBy not obsessing over primitives, they made it so that all methods that use times can accept any time. You don't have to constantly remind yourself what the context for that time value is (e.g. seconds, milliseconds, etc), because the method doesn't specify the context, you do. So I love the idea of better contextualizing values beyond their strict storage type. As long as there's a useful context that adds value. From your example, I think an
Angleabstraction that handled both radians and degrees could prove useful in a similar manner toDuration, for example. As given, I'm not sure abstracting adoubleto anAnglesolely to remove the primitive is a good pattern though. My assumption is that the intention is to force the developer to explicitly contextualize the double value, but the thing is if the developer didn't care about the context before, they aren't going to care now. They'll just wrap the double they have and move on (e.g.ex.handleAngle(new Angle(someDoubleThatIsntAnAngle))). Elevating a primitive in this way doesn't actually achieve anything that variable naming and/or named arguments couldn't already do. Just having a nondescriptAnglewith adoublesize property does nothing to further describe adouble angleparameter. There has to be more sauce to it to make the abstraction worth it in my opinion.That's a nice example of a good use of creating types for the parameters and it makes sense. Also, I'm just at the beginning of the author's example also and it seems he is taking the example much further so it probably isn't that the author is actually saying "well, just wrap all those primitives in structs" but is building the case for it as he continues his longer example. I was just astonished to see this "newer" idea of wrapping primitives like that. I will continue reading the book because it is making me think different and the author's point is to make "more readable" code too and any hints toward that always go a long way. Thanks for your interesting post which really adds to the conversation.
-
The SGML v XML discussion is a perfect example of it, for sure. And speaking of JSON -- the detractors for JSON want this new, new, new THING!! (RUST uses it) It's called TOML (Tom's Obvious, Minimal Language[^]). TOML is so amazing!! It's so new. It's never been seen before!!!! Squeeeeee!! Oh, wait, Windows 3.1 Ini files[^] used that same format. 😅😆🤣🤓
raddevus wrote:
Oh, wait, Windows 3.1 Ini files[^] used that same format.
Ha ha ha ha. That's so true. In fact, one of the reasons I haven't really decided to learn Rust yet is it's _too_ opinionated.
Jeremy Falcon
-
That's a nice example of a good use of creating types for the parameters and it makes sense. Also, I'm just at the beginning of the author's example also and it seems he is taking the example much further so it probably isn't that the author is actually saying "well, just wrap all those primitives in structs" but is building the case for it as he continues his longer example. I was just astonished to see this "newer" idea of wrapping primitives like that. I will continue reading the book because it is making me think different and the author's point is to make "more readable" code too and any hints toward that always go a long way. Thanks for your interesting post which really adds to the conversation.
Might wanna check my new, new reply. I'm being annoying in it. :laugh:
Jeremy Falcon
-
I've been working a lot lately with Spring Webflux/Reactor and they liberally use the
Durationclass for any time specs.//so instead of
long ticks
long ms
long s
//etc, etc, you see
Duration t
//and you create values using stuff like
Duration.ofSeconds
Duration.ofMillisecondsBy not obsessing over primitives, they made it so that all methods that use times can accept any time. You don't have to constantly remind yourself what the context for that time value is (e.g. seconds, milliseconds, etc), because the method doesn't specify the context, you do. So I love the idea of better contextualizing values beyond their strict storage type. As long as there's a useful context that adds value. From your example, I think an
Angleabstraction that handled both radians and degrees could prove useful in a similar manner toDuration, for example. As given, I'm not sure abstracting adoubleto anAnglesolely to remove the primitive is a good pattern though. My assumption is that the intention is to force the developer to explicitly contextualize the double value, but the thing is if the developer didn't care about the context before, they aren't going to care now. They'll just wrap the double they have and move on (e.g.ex.handleAngle(new Angle(someDoubleThatIsntAnAngle))). Elevating a primitive in this way doesn't actually achieve anything that variable naming and/or named arguments couldn't already do. Just having a nondescriptAnglewith adoublesize property does nothing to further describe adouble angleparameter. There has to be more sauce to it to make the abstraction worth it in my opinion.Realistically though, how often do you need to contextual _inputs_ like that? If it's external user input, it should always be sanitized first. Which means you can transform any exceptions in that layer. If it's internal user input, how often do you really change contexts like that in practice? Don't get me wrong, nothing against structs as a param, but having said logic to handle the contextualization in every last routine that uses it (it's for inputs) isn't ideal. I'd argue structs are useful for abstracting complex data types only, irrespective of the context in which they are called with.
Jeremy Falcon
-
Greg Utas wrote:
It can easily cause bugs when, for example, a plain integer is interpreted as a time duration. Was that in seconds? Milliseconds? Microseconds?
Yes, I agree. That is a very good example of where this struct wrapper would be highly beneficial. And, I do like the discussion around "using more structs". It is just interesting that in the past, it was "everything is a class" and to see that re-thought.
In C++, there's no difference between
classand astruct, so that comparison with C# is likely to be misleading. In C++, the two keywords often have different semantics by convention, but they're the same to the compiler. If you look at the STL's , there's no way to confuse a duration in seconds with one in milliseconds. Their object wrapper precludes it.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Just started reading this (just released) book, The C# Type System (no starch press)[^] and the first chapter is kind of blowing my mind. Step 1 Author starts out with the following example and says, "You must use better named variables so dev users know what they mean."
Displacement(double t, double v, double s)
{
var x = v * s * Math.Cos(t);
var y = v * s * Math.Sin(t) - 0.5 * 9.81 * Math.Pow(s, 2);
return (x, y);
}Yes, that makes sense. Step 2 Then he says, "Oh, you can add meaning with this new idea of named arguments so users don't have to remember order that they should be passed in."
var result = Displacement(angle: .523, speed: 65, elapsedTime: 4);
Ok, yes, that is good advice with the modern capabilities. Step 3 May Blow Your Mind He mentions that the code is still confusing because all three arguments are the same primitive type (double) and this leads into...
From the book:
Primitive Obsession code smell, which describes any code that has an overreliance on primitive types—that is, those types that are built into the language, such as int, double, and string.
The solution is... Wrap All the Primitive Types In Structs 🤯🤯🤯🤯🤯
public struct Angle
{
public double Size {get; set;}
}
public struct Speed
{
public double Amount {get; set;}
}The Paradigm Has Shifted Now, when the user attempts to call the
Displacementmethod the compiler will know that the argument type is wrong. Now, there's no way to pass the wrong value into the method, because the compiler will know the type. Wow, that is a very different paradigm!! Step 4 Is Immutability Now, make each struct immutableI think it's similar to the old "bool-vs-enum" arguments that have been around for many years. An appropriately-named enum can certainly make the calling code easier to read than a bunch-o-bools, although it can lead to some interesting definitions[^]. :) Given how recent the book is, I'm surprised the author hasn't progressed to record structs[^]; perhaps that will come later?
public readonly record struct Speed(double Amount);
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Just started reading this (just released) book, The C# Type System (no starch press)[^] and the first chapter is kind of blowing my mind. Step 1 Author starts out with the following example and says, "You must use better named variables so dev users know what they mean."
Displacement(double t, double v, double s)
{
var x = v * s * Math.Cos(t);
var y = v * s * Math.Sin(t) - 0.5 * 9.81 * Math.Pow(s, 2);
return (x, y);
}Yes, that makes sense. Step 2 Then he says, "Oh, you can add meaning with this new idea of named arguments so users don't have to remember order that they should be passed in."
var result = Displacement(angle: .523, speed: 65, elapsedTime: 4);
Ok, yes, that is good advice with the modern capabilities. Step 3 May Blow Your Mind He mentions that the code is still confusing because all three arguments are the same primitive type (double) and this leads into...
From the book:
Primitive Obsession code smell, which describes any code that has an overreliance on primitive types—that is, those types that are built into the language, such as int, double, and string.
The solution is... Wrap All the Primitive Types In Structs 🤯🤯🤯🤯🤯
public struct Angle
{
public double Size {get; set;}
}
public struct Speed
{
public double Amount {get; set;}
}The Paradigm Has Shifted Now, when the user attempts to call the
Displacementmethod the compiler will know that the argument type is wrong. Now, there's no way to pass the wrong value into the method, because the compiler will know the type. Wow, that is a very different paradigm!! Step 4 Is Immutability Now, make each struct immutableHe failed step 3. Angle is not very well implemented, as it does not specify what unit it uses. Either call it Radians, or specify the unit in the constructor and getter. Ironically, this could possibly be implemented by inheritance. Angle being the base class and Degrees, Radians, Turns and Gons (optionally Longitude and Latitude) being the sub classes, although this would force it to be a class. As implemented the client of this function could still create an angle of 90 (thinking degrees) and pass this in and get a point at 90 radians. I agree that is is a good idea to make structs immutable. I have seen so many bugs caused by trying to alter a Point or Size but the code is altering a copy, not the original. Is implementing structs for these a good idea? Possibly. I have implemented Angle as a class before - mainly for user display. I have also just used angleDegrees and angleRadians. Choose wisely. The advantages are it forces the correct type to be passed in. The disadvantages are a little bit of speed and extra code. Would naming the angle as angleRadians be enough to eliminate most errors? Do we need explicit casts on Radians so we can use (Radians)Math.PI? Personally I prefer a plain double, named well, although an explicit type can be useful.
-
He failed step 3. Angle is not very well implemented, as it does not specify what unit it uses. Either call it Radians, or specify the unit in the constructor and getter. Ironically, this could possibly be implemented by inheritance. Angle being the base class and Degrees, Radians, Turns and Gons (optionally Longitude and Latitude) being the sub classes, although this would force it to be a class. As implemented the client of this function could still create an angle of 90 (thinking degrees) and pass this in and get a point at 90 radians. I agree that is is a good idea to make structs immutable. I have seen so many bugs caused by trying to alter a Point or Size but the code is altering a copy, not the original. Is implementing structs for these a good idea? Possibly. I have implemented Angle as a class before - mainly for user display. I have also just used angleDegrees and angleRadians. Choose wisely. The advantages are it forces the correct type to be passed in. The disadvantages are a little bit of speed and extra code. Would naming the angle as angleRadians be enough to eliminate most errors? Do we need explicit casts on Radians so we can use (Radians)Math.PI? Personally I prefer a plain double, named well, although an explicit type can be useful.
"I prefer a plain double, named well" I agree. Working in embedded systems where units are very important, I try to always include units at the end of the variable name. It causes a mental check when you start misusing the variable. But I also like a little more rigidity to avoid really stupid errors. I'm thinking of the Mars Climate Orbiter that lawn darted due to a units conversion issue. Errors like this boggle my mind. Every engineering system should be in metric. Period. If you want to convert something to English - that's a presentation issue, but I digress. This conversation is an excellent read.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
I think it's similar to the old "bool-vs-enum" arguments that have been around for many years. An appropriately-named enum can certainly make the calling code easier to read than a bunch-o-bools, although it can lead to some interesting definitions[^]. :) Given how recent the book is, I'm surprised the author hasn't progressed to record structs[^]; perhaps that will come later?
public readonly record struct Speed(double Amount);
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Richard Deeming wrote:
An appropriately-named enum can certainly make the calling code easier to read than a bunch-o-bools, although it can lead to some interesting definitions[^].
In my student days, DEC had a discussion group system called COM, not unlike the far more well known NetNews, running on DEC-10 and DEC-20 mainframes. Whenever the software asked the user a yes/no question (such as "Delete entry?") there were in fact three options: Yes, No, Maybe. If the user chose Maybe, a random generator was used to choose between Yes and No. This was a fully documented, well known feature. I believe this feature existed in the old DEC-10/20 version. COM was completely rewritten as a platform independent system and renamed PortaCOM. I used the system in the transition from COM to PortaCOM; maybe the 'Maybe' option came with the PortaCOM rewrite. I didn't discover it until we had switched to PortaCOM.
-
"I prefer a plain double, named well" I agree. Working in embedded systems where units are very important, I try to always include units at the end of the variable name. It causes a mental check when you start misusing the variable. But I also like a little more rigidity to avoid really stupid errors. I'm thinking of the Mars Climate Orbiter that lawn darted due to a units conversion issue. Errors like this boggle my mind. Every engineering system should be in metric. Period. If you want to convert something to English - that's a presentation issue, but I digress. This conversation is an excellent read.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
charlieg wrote:
I'm thinking of the Mars Climate Orbiter that lawn darted due to a units conversion issue.
A less known story of a similar kind: In its infancy in the late 1960s, the Norwegian computer manufacturer Norsk Data started buying standard 19" power supplies, and tried to build their own 19" racks. They ended up as being rather roomy, the power supplies almost fell down. It was tracked down to the mechanics having calculated the metric equivalent of 19" on the old Norwegian inch of 25.6 mm, rather than the American 25.4 mm inch. 19 times 0.2 mm = 3.8 mm. Not terribly much extra, but enough to require some extra care for the power supplies to be securely fastened. (According to Wikipedia, the SI inch definition of 25.4 mm was almost ten years old at the time, but it takes much more than ten years to change tooling and conversion factors. (And I am not going to bring up metrication in the US of A to prove my point.))
-
Realistically though, how often do you need to contextual _inputs_ like that? If it's external user input, it should always be sanitized first. Which means you can transform any exceptions in that layer. If it's internal user input, how often do you really change contexts like that in practice? Don't get me wrong, nothing against structs as a param, but having said logic to handle the contextualization in every last routine that uses it (it's for inputs) isn't ideal. I'd argue structs are useful for abstracting complex data types only, irrespective of the context in which they are called with.
Jeremy Falcon
I agree it's easy to go overboard with it. That's why I mentioned I feel like there has to be "more sauce" to the abstraction - e.g. an abstraction that abstracts multiple parameters, an abstraction that adds functionality, etc. As a more concrete example with the Angle idea - you have Radians and Degrees as options (so Angle is basically an Either sum type) and Radians and Degrees are isomorphic. Why is that useful? Here's some pseudo-code:
class Angle = Radian | Degree
(+) :: Angle a -> Angle b -> Angle c
(+) x = match x
| Radian z => \y -> z + toRadian(y)
| Degree z => \y -> z + toDegree(y)public double addRightAngle(double degrees) => degrees + 90; //Fails if you pass in radians
public double addRightAngle(double radians) => radians + (90*(pi/180)); //Fails if you pass in degrees
public Angle addRightAngle(Angle angle) => angle + new Degree(90); //Succeeds in all cases
public Angle addRightAngle(Angle angle) => angle + new Radian(1.5708); //Succeeds in all casesHow useful this is depends on how important angles are to your code-base, but I think abstracting inputs is very powerful. Another example is if you're doing functional programming and have a function that accepts impure inputs like a database function. You can group all impure inputs together into a tuple and shift that tuple to the right of the parameter list. This effectively turns your function into a pure function that returns an impure Reader with that environment tuple as input and the result as output (i.e. "functional" dependency injection). Makes a lot of things easier especially unit testing. Credit to Mark Seemann for that insight[^].
-
That's a nice example of a good use of creating types for the parameters and it makes sense. Also, I'm just at the beginning of the author's example also and it seems he is taking the example much further so it probably isn't that the author is actually saying "well, just wrap all those primitives in structs" but is building the case for it as he continues his longer example. I was just astonished to see this "newer" idea of wrapping primitives like that. I will continue reading the book because it is making me think different and the author's point is to make "more readable" code too and any hints toward that always go a long way. Thanks for your interesting post which really adds to the conversation.
That's awesome! I've been learning universal algebra and category theory recently for a similar purpose. Having a new perspective on things really opens up your problems solving ability. I feel like I'm less of a hammer looking at everything like a nail.
-
He failed step 3. Angle is not very well implemented, as it does not specify what unit it uses. Either call it Radians, or specify the unit in the constructor and getter. Ironically, this could possibly be implemented by inheritance. Angle being the base class and Degrees, Radians, Turns and Gons (optionally Longitude and Latitude) being the sub classes, although this would force it to be a class. As implemented the client of this function could still create an angle of 90 (thinking degrees) and pass this in and get a point at 90 radians. I agree that is is a good idea to make structs immutable. I have seen so many bugs caused by trying to alter a Point or Size but the code is altering a copy, not the original. Is implementing structs for these a good idea? Possibly. I have implemented Angle as a class before - mainly for user display. I have also just used angleDegrees and angleRadians. Choose wisely. The advantages are it forces the correct type to be passed in. The disadvantages are a little bit of speed and extra code. Would naming the angle as angleRadians be enough to eliminate most errors? Do we need explicit casts on Radians so we can use (Radians)Math.PI? Personally I prefer a plain double, named well, although an explicit type can be useful.
Surely most of these problems can be circumvented by using sensible variable or parameter names, eg AngleInRadians", "ElapsedTimeInMillisec" etc? Saves a lot of coding time, and however you try to avoid it, if a developer is determined to be dumb, he or she will be, whatever.
-
Very interesting post. Thanks for sharing. :thumbsup:
trønderen wrote:
There are so many grains of gold in old, phased-out technology.
I agree, but this is what drives IT, I guess. It's either jump on the bandwagon or it rolls over you. :-D It's shiny and new!! :rolleyes:
There are too many Magpies in software development. Cannot resist anything shiny and new! And too many who instead of offering their opinion for critique, seek to impose it as the New Standard.
