104

How does a Function Programming, such as Elm, achieve "No runtime exceptions"? That's easy. You simply don't write functions that fail. That might sound simplistic, but that's the gist of it. Take division, for example. We can simply define that anything divided by 0 is 42. Boom. Now, division no longer throws a runtime exception, it just ...


17

It's not quite zero-overhead, but you can use the GLFWwindow User Pointer Property to make a relatively clean solution, I think (caveat: my C++ is a little rusty, and I am not familiar with the GLFW library). In your Window constructor, Window(...) { // ... glfwSetWindowUserPointer(mHandle, static_cast<void *>(this)); ...


16

How the Functional Paradigm or programming approach eliminates runtime exceptions? Elm does it by encoding return values as Maybe or Result instead of causing a runtime error. type Result error value = Ok value | Err error Are runtime exceptions a great disadvantage of OOP over Functional Programming? As I understand it, the goal of Elm is to make the ...


15

It doesn't remove errors. It just uses the type system to force you to handle all errors explicitly. To understand Maybe types, you had to go back to older languages like C that doesn't have Exception. In C, errors are usually indicated by returning status/error code that you have to remember to check every time you do an operation. The problem with this ...


15

You misunderstood the “zero overhead” principles. It means that features of the C++ language should have zero overhead if you don’t use the feature. For example, exceptions have overhead if you use them, and that’s fine, but the fact alone that the language supports exceptions causes no runtime overhead if you don’t use them.


13

A flawed example of LSP One thing that I want to touch on but not dig deeply into: the common SOLID examples were not designed to be scrutinized as much as we've ended up scrutinizing them. They are simple examples, and weren't intended to be countered using complex interpretation of possible additional circumstance or requirements. You can find fault in ...


7

Two things occur to me that look ugly to my eye. IMHO the things you mentioned look quite less ugly to me than they were before. in the constructor to my Matrix class -- at the point when I know what the fixed size of the matrix will be -- I won't be calling the vector's constructor, but rather the function elem.resize() It depends on the point where you ...


6

Run-time exceptions are not related to the programming paradigm chosen, but to the fact that whatever the language chosen, something can go wrong at run-time: Exception handling emerged as a special control flow mechanism before OOP, and appeared in the context of structured programming in PL/1 in the 70s. Functional programming languages handle exception ...


4

Whatever you mean with immutability, immutability is not broken here. You seem to refer to classes and consider that class A is modified by inheritance. But this is not what inheritance is about: class T exists first, and class A is defined as a specialization of T. This means that the class T continues to exist, unchanged, and class A is defined based on T ...


4

The most popular description of this principle is simply "A subclass must be replaceable with it's base class without breaking the program". I have a couple of things to say about this. First, some general advice: correctness is not a popularity contest. Just because this description is “the most popular” does not make it right. It is, in fact, ...


3

A bean with 30+ fields, only one of which can be set, and none of whom are very related, seems awkward. Would it be possible to have each of the fields classes know how to process itself? e.g. in Java syntax (with a lot of loose ends) interface CanProcess { void process(some arguments); } class PersonalInfo implements CanProcess { void process(some ...


2

The core idea of functional programming is choosing the right types for your function. I will borrow the example of an easy and most evident example. Divide // Note: Scala Code // Here you cannot avoid the exception, // because your function is tied to a primitive data type def divide: (Float,Float) => Float = (a, b) => a / b // Here the function ...


2

A always inherited T, and T always contained the goto method, so it was not mutated. Mutability refers to class instances. You're talking about class definitions, and therefore mutability is not relevant to discuss here. If you are unsure what I mean by class instances as opposed to class definitions (which I suspect you might be, based on your question), ...


2

It is not breaking immutability. Because A does not change any member field of T instance, and method goto in T does not allow inherited class to change anything of its instance either.


2

Mixins are a way to compose functionality at the level of classes instead of using object composition. The idea is to have a base class and enrich it by combining it with reusable mixins using multiple inheritance. Since mixins do not really define a type, you should not instantiate them. You already got this. The usual way is therefore to have an ...


1

As others have pointed out, the core difference here is in the way the effect of an exceptional situation is handled. In functional programming, it is somewhat common to encode the possible exception states into the return type. This can get a bit conflated when you start having both business errors and technical exceptions encoded into the same error ...


1

"Premature abstraction" means (in a code review): "I think it is too early to tell what an appropriate abstraction to use is, and if we starting using this abstraction it might make it harder to see and switch to a more appropriate abstraction later." So if someone tells you your abstraction is "premature", here are some ...


1

Expressiveness is in the eye of the beholder. (Many famous programmers have used the word "expressiveness" to mean different things, sometimes in contradictory ways.) To appreciate Bjarne Stroustrup's approach for C++, one has to be armed with intimate knowledge with the lower level working of C++, such as memory allocations, the standard library, ...


1

After some thought, I think the second code snippet does not use the Factory method as it is not concerned with the creation of objects. However, the code can be refactored to use the Factory method and better communicate the intent: class CraneInterface(ABC): def __init__(self): self.__axis = self._make_axis() @property def axis(self) -...


1

How far down the rabbit hole do you want to go? The C++ virtual function table based dynamic dispatch is just one OO model. You can implement others, and your code is still C++. Suppose you want to have a polymorphic method without vtable overhead. template<class T> using ptr_to = T*; template<auto F, class T> struct Operation { constexpr ...


1

Proposed solution I propose a bunch of static "dispatcher" functions, which would lookup the right Window instance and then forward the received GLFWwindow* to that instance, so it could do the real work: class Window { // // // Part 1: object-oriented UI stuff // // // float _coolnessFactor; /* your data members */ Window (/*params?*/) ...


Only top voted, non community-wiki answers of a minimum length are eligible