Value Oriented Programming Part V - Return of the Values - Tony Van Eerd - C++Now 2024
Вставка
- Опубліковано 28 гру 2024
- www.cppnow.org
---
Value Oriented Programming Part V - Return of the Values - Tony Van Eerd - C++Now 2024
---
At the very first C++Now (aka BoostCon 2007), Sean Parent gave the Best. Keynote. Ever. Introducing many to Value Semantics. Some (who are probably reading this) said it fundamentally changed how they code. During the questions at the end, Dave Abrahams asked "how do we teach this".
We are trying Dave, we are trying.
"Value Oriented Programming" is the new thing. As opposed to Object Oriented Programming, obviously. But what is it?
It is actually somewhat less about Values vs Objects, but more about the "Oriented" part. A class, or even an int, can be treated "value-y" or "object-y", but the goal (we will see) is to more often favour an orientation towards value semantics.
We will look at how to make your types lean towards values, and how to make your code and functions treat your types like values. We will cover Intrinsics, Extrinsics, Invariants, and more!
The goal is improved code readability, correctness, maintainability, testability, and maybe even performance.
P.S. yeah, I know, the episode number should be VI...
---
Sponsored by Undo: Debug your hardest C++ bugs with time travel debugging → Learn more at bit.ly/cppnow24
---
Tony Van Eerd
Tony has been coding for well over 25 years, and hopefully coding well for most of that. Previously at Inscriber, Adobe, and BlackBerry, he now enables painting with light at Christie Digital. He is on the C++ Committee. He is a Ninja and a Jedi.
---
C++Now 2025 - 28th April - 2nd May
C++Now is an annual onsite international C++ programming and coding conference held in Aspen, Colarado. For all C++ developers, C++ software engineers and those involved with the C++ language, CppNow provides an indepth and technical content provided by the best and brightest C++ experts of the C++ world.
Annual CppNow Conference - www.cppnow.org
/ cppnow
/ cppnow
/ cppnow
/ cppnow
mastodon.socia...
Video Sponsors: millennium and think-cell
---
Videos Filmed & Edited By Bash Films: bashfilms.com/
UA-cam Channel Managed & Optimized By Digital Medium Ltd: events.digital...
---
#boost #cpp #cppprogramming #coding #programming
I liked seeing the Law of Demeter at 30:03. I just kind of realized that myself a couple months ago writing Haskell code: I had written a function that performed pretty deep pattern matching, and worked fine - but when I added some features, I had to refactor it into functions that each pattern matched only one level at a time. It was better code!
In particular, if you have a Haskell list, it's probably a good idea NOT to write functions that pattern match [Foo] for some particular Foo: write a function that takes a Foo only, and use some kind of map or fold to apply it to your [Foo] list.
Now I have a name for that idea. I hadn't really given it a name: I had expressed it to myself only as "A function should not generally take, or branch on, the value contained inside of a particular instantiation of a parametric type: it's better to compose a parametric function over the parametric type with a function that deals with the particular type it's been instantiated with". Law of Demeter is a decent name for that.
Great talk Tony!
An interesting presentation. After watching it, I found myself wanting some sort of list of questions to answer about a data type you are about to code that would tell you whether you should think of it as a value or an object. I guess something like a decision tree. I realize the decision is not that simple but it might be a good starting point nonetheless.
A list a questions would be useful - that's a great idea.
Typically I "just know" which I want (and typically it is values), but there are probably times it is less clear.
I think the slide with Objects vs Values and their properties (ie at 1:14:32) might be a start.
@@tvaneerd After thinking about it a little more, I guess I also "just know" but fear that there are edge cases where I go with object but could have gone with value and made the code simpler and more reliable. Figuring out how to identify those edge cases is perhaps what it is really about.
Clojure mentioned.
What's the problem? The answer to the "Ship of Theseus" question is right there in the question. The ship of Theseus is obviously the ship that belongs to Theseus. If Theseus chooses to replace parts and throw the old parts away then clearly he still owns a ship, that is the ship of Theseus. If someone else collects the reject parts and builds them up into a ship that is clearly not the ship of Theseus, that is the ship of whoever's name. This train of thought seems to be all about ownership and lifetimes. Correct handling of ownership and lifetimes is one of the many reasons I have stopped using C++ and moved to Rust.
I'm still getting trouble to find a good 3d point able to work seamless in cartesian and polar coordinates and being a struct.
using Point3D = variant;
😂
mycolouredcircle = colour{other}
Fabulous! But what about Rust?!!