91–100 of 268 posts
Earlier quoted context omitted.
This article discusses object/class inheritance in programming languages, not wealth inheritance between people.
There’s a difference?
Pretty off topic comment, but I read the title as "inheriting money is a way avoid being a high performer", which happens to be true, although completely irrelevant to the actual article. ;)
This is why I'm not a biologist (or OOP fan). :)
Pretty off topic comment, but I read the title as "inheriting money is a way avoid being a high performer", which happens to be true, although completely irrelevant to the actual article. ;)
After reading all the comments of many confused and curious, here is when inheritance is bad and why so _in the absence of any performance considerations_. First, inheritance from an interface/trait is totally okay. The problem is class inheritance, meaning implementation inheritance. There are two cases: 1) you inherit from a class and only add methods but don't overwrite anything. This is the good case, you can do…
> This problem is impossible to fix and it is a general problem - when overwriting a method, you can never be sure that semantics could break when the base class is changed. I'm not sure what's so special about overwriting methods here. There are many cases where semantics can break as a dependency changes. One example would be whether a callback is executed on the same thread (or event-loop tick) or in the backgroun…
Rust's Send and Sync traits solve this particular problem by putting the thread-send safety in the type signature. If the library changes to use a background thread and you have passed it a non-threadsafe closure then you'll get a compile error.
Pretty off topic comment, but I read the title as "inheriting money is a way avoid being a high performer", which happens to be true, although completely irrelevant to the actual article. ;)
I read the title as "new hypothesis about evolutionary theory and gene inheritance". This is why I'm not a biologist (or OOP fan). :)
Earlier quoted context omitted.
Theory usually comes after practice. People create something that works, then theorists formalizes it into a well defined concept.
I hold the view that programming patterns were invented as solutions to technical problems. It was then later that some theoretical "usefulness" or "elegance" was attached to them. One should know the technical benefits and drawbacks of programming patterns before applying them. Just because some language or environment or majority of programmers promotes it, doesn't mean that its ok to apply it. Without knowing the…
Earlier quoted context omitted.
Theory usually comes after practice. People create something that works, then theorists formalizes it into a well defined concept.
I hold the view that programming patterns were invented as solutions to technical problems. It was then later that some theoretical "usefulness" or "elegance" was attached to them. One should know the technical benefits and drawbacks of programming patterns before applying them. Just because some language or environment or majority of programmers promotes it, doesn't mean that its ok to apply it. Without knowing the…
IIRC, there was impetus from Christopher Alexander's architectural "pattern language", and the desire to do something similar in software, which was a bit of an unguided mess at the time.
Earlier quoted context omitted.
Theory usually comes after practice. People create something that works, then theorists formalizes it into a well defined concept.
I hold the view that programming patterns were invented as solutions to technical problems. It was then later that some theoretical "usefulness" or "elegance" was attached to them. One should know the technical benefits and drawbacks of programming patterns before applying them. Just because some language or environment or majority of programmers promotes it, doesn't mean that its ok to apply it. Without knowing the…
Turns out in C# there's no syntactic difference between implementing an interface and inheritance, so it makes sense in C# to explicitly state that something is an interface but, arguably, only there.
tl;dr: > Simula created inheritance instead of using composition because it allowed their garbage collector to be simpler. In C++, inheritance (and other OO languages I assume) is implemented as a composition and when multiple inheritance of the same class happens then the members of the twice parent is inherited twice unless the virtual keyword is used. ( in other words, if B : A, A, C then sizeof B = A + A + C + B'…
Doesn’t Parent parent = Child() work because Parent’s constructor is run by implicitly casting ref-to-Child to ref-to-Parent?
I think what TeeMassive is saying is that this rejigging is a simple truncation because the memory layout of (non virtual) inheritance in C++ is a concatenation of Parent and Child objects. I'm not sure whether this is implementation specific though.
After reading all the comments of many confused and curious, here is when inheritance is bad and why so _in the absence of any performance considerations_. First, inheritance from an interface/trait is totally okay. The problem is class inheritance, meaning implementation inheritance. There are two cases: 1) you inherit from a class and only add methods but don't overwrite anything. This is the good case, you can do…
People write working code using inheritance, it's not impossible, just requires extra care. One example:
class CountingStack() {
def push(element) returns nothing =
count += 1; super.push(element)
override def pop() returns element =
count -= 1; super.pop(element)
}
class Stack() {
def nonvirtual private push_internal(element) returns nothing = ...
def push(element) returns nothing = push_internal(element)
def pushAll(elementlist) returns nothing = ... // use push_internal if needed
def pop() returns element = ...
}
IMHO the main problem is encapsulation. People expect the code to work one way and don't check their assumptions because of the whole tower of abstractions and hiding what actually happens behind layers. And then instead of writing straightforward code to do what has to be done - you have to tiptoe around all possible implementations :)