Specification Inheritance And Behavioural Subtyping: Fill & Download for Free

The most important distinction is how you create objects.Python is a class-based object-oriented programming language. In Python, you define a class, which is a kind of template, blueprint or simply a definition, from which you can create objects. The class defines the structure and behaviour (methods) of its objects Each object is an instance of a class, and the object’s type is its class. Inheritance, where you can define a hierarchy of subtypes of objects that inherit functionality and builds upon each other, is done by subclassing other classes, creating a more specific class.JavaScript is a prototype-based programming language. Here, existing objects serve as the templates for new objects. You clone an object, the prototype, to create a new object. This new object inherits its prototype’s functionality through delegation, which means that JavaScript will know what the prototype of an object is and look it up if necessary, making changes to the prototype appear in the clone as well, but not the other way around; this is how inheritance works. The new object can be extended in run-time by adding, rebinding and deleting properties at will; objects in JavaScript are really just associative arrays (the same thing as “dicts” in Python).

Hello,Because people have very difficult to understand that there is multiple inheritance in java. It’s just hidden by different keywords ;)Let me explain this point of view:Basically, inheritance is just subtyping and allows the substitution phenomen, in the terms of the LSP (Liskov Substitution Principle).If you take a look at java, classes may extends other classes and implements interfaces, in a scheme like/* Note that the Base class implicitely extends the Object class  */ public class Base{  /* ... */ }; public interface MyInterface{  /* ... */ };  public class Derived : extends Base,  implement MyInterface{  /* ... */ }; Do you agree with that?It sounds like if extends and implements keywords were different kinds of thing, true? But, they don’t.You surely think that I’m crasy, because “extends” states for inheritance and “implements” states for “implementation”, whose are two different things. But, are you sure of this? Go just a little farest, and provide an User class, which looks likepublic class User{  public static void main(int args, char * argv[]){  /* ...*/  }  public void useClass( Base b){  /* ... */  }  public void useInterface(MyInterface i){  /* ...*/  } }; Such class is perfectly valid in Java, right?I can call the useClass function with any object used as it were of type Base (including with an object of type Derived, since Derived class is just a specialization of the Base class).And I can call the useInterface function with any object whose implements MyInterface (including any object of type Derived, since Derived class implements the interface MyInterface).Do you always agree with that? Of course, because I just have resumed two of main functionalities in java ;)Well… Now that we have the same starting point, let me a question: What conceptual principle is java based on to allow those behaviours?For the useClass function, I can give a name (already given): the Liskov Substitution Principle.But, I cannot imagine that people having developped java could have allowed a so basic behaviour as passing any object implementing an interface to a function waiting for an instance of this intereface without basing it on a conceptual principle.If inheritance and implementation were really different things, you should then have a second conceptual principle which speaks specifically about substituing interfaces.But, there is no such principle. Or, at least, I’m looking for such principle for ten years now, and I haven’t find it for now.Einstein saidMake things as complex as needed, but no moreAnd I will follow his advise:If I can name the principle which allow to substitute a base class by one of its derived when calling useClass function, without being able to name the concept allowing to substitute to an interface any instance of class which implements it when calling useInterface function.As far as behaviours will be exactly the same (even if we’re speaking about class at a side and about interface at the other), doesn’t it means that there is just one single principle which fits perfectly for both function calls?Ouuggghhh… But, LSP doesn’t speak about classes or interfaces. It just speaks about subtyping and provable properties. I copy it for memory:subtypes requirements: Let o(x) be a property provable about object x of type T. Then o(y) should be true for objects y of type S where S is a subtype of T.What conclusion could we draw of it?My conclusion is that extends and implments keywords are two different words to state the same thing : subtyping. They just impose different kinds of restrictions in theire use :extends applies on base types introduced by the class keyword, and allow only one subtyping using it whenimplements applies on base type introduced by the interface keyword, and allow multiple subtyping using it.But, basically, they both are speaking about subtyping. You just have to consider restrictions imposed by the implements keyword as partial, because a second part is given by the interface keyword:An interface cannot have any data. It’s a type gender which only exposes … functions. And, as far as they are no data to provide a viable implementation of those functions, you cannot instanciate your interfaces directly (undersand: without passing by a class which implements them).Finally, inheritance is just subtyping. The extends keyword allows you subtyping classes. The implements keywords allows you subtyping interfaces.You can use extends keyword only once in a derived class, but you can use implements keyword as many as you like / need.So, you can have multiple inheritance in java. It’s just hidden by different keywords ;)PS: Please forgive my poor English, my mother tongue is French.

I can’t really speak for other people, so this answer will be about what I consider bad in OO programming. Some of it may coincide with what other people consider bad in the model.(by the way, much of the criticism here applies to my own language, Siren, too)Summary:I) Safe & modular extension of operations is not practical in existing OO languages or in existing research on this exact problem;II) Mainstream OO (Java, C++, Python, Ruby, JS, Scala, Swift, …) can’t use much of the foundations/recent research, requires too many design patterns to circumvent limitations;III) Most OO languages are unsafe in the presence of untrusted code;IV) Most OO languages do not support multiple dispatch, results in awkward design decisions/asymmetry problems;V) Some OO concepts (e.g.: inheritance) are too complex compared to solutions to the same problem of reuse in other models;VI) Closer-to-Kay’s vision environments for OO (Pharo, Squeak, Self, …) require significant investment due to lack of popularity/mismatch with OS tools;VII) In most languages, concurrency tends to be a bigger issue than in FP;VIII) Static checking (type systems) requires you to give up on more advanced features/tooling that OO environments promise; Even practical type systems tend to be much more complicated than FP ones because of subtyping;I) SAFE/MODULAR EXTENSIONPrograms are increasingly more complex, and a lot of parts of a system are not written/owned by the people writing the system. We use a lot of third-party libraries and frameworks. Sometimes, we need these objects written by other people to do additional things, or fit into different places, but we don’t have access to the source code, and changing it directly would mean that we have to maintain it anyway. Wadler calls this the Expression Problem[1]. Object orientation makes solving this problem harder than FP, because it bundles behaviour and data together. The current solutions are far from ideal.Current solutions:design patterns[2] (Adapter[3]) and object algebras[4] require too much boilerplate, and tend to require significantly more effort in typed languages;open classes[5] are inherently unsafe, unpredictable, and hostile to future changes — they are not modular;extension methods[6] are not object oriented, and are limited to static, lexical contexts;protocols[7] and multimethods[8] are better solutions, but tend to enforce some kind of global coherence[9], so they are not modular[10] — note that this also applies to Type Classes in Haskell;not using OO. This is where all those dreaded utility classes come from, which are really FP/procedural programming. This is a no-solution for OO, but people use it because it solves the problem they need to;Solutions we get from extending Object Oriented programming to a superset of the model:Aspect-Oriented Programming[11] makes understanding the behaviour of programs much more difficult, because pieces are all over the place;Subjective/Context-Oriented Programming[12] makes understanding dispatch much more difficult, because each dispatch depends on implicit context that’s not available at the call-site;Implicit Calculus[13] (which Scala uses) are very modular and somewhat easier to reason about, but not globally coherent. This gives us some interesting issues[14];Now, you can limit some of the problems above by limiting the pervasiveness of these features (for example, Siren limits contexts to explicit opt-in in a lexical context[15]), but then you get other problems with adaptability of existing code or with coherence. Plus, they’re not really that well researched yet (context-oriented programming is hard to optimise, implicit calculus is from 2012, etc).So, yeah, we don’t have good solutions here, but OO languages suffer more with this than FP languages because objects merge behaviours and data structures.II) MAINSTREAM OO IS NOT QUITE “OO”And here I’m not even talking about the problem with the definition of the term “object oriented,” but rather that mainstream languages are generally multi-paradigm, so they offer more than one fundamental model which you can use to solve the problems.That’s all well and good, except that composition between these different features are now much more complicated than if they were all build from the same basic-building block. Some of these don’t really compose (see Java’s lambdas or JavaScript’s getters/setters). This results in programs that require a different mindset to be understood in different parts, but also in programs that you can’t abstract in an uniform way.For example, Python allows you to have list comprehensions, but list comprehensions are not built upon object-oriented features, it’s its own sub-language, with its own rules, and its own abstraction facilities. Java separates methods from members, if some class has a public member X, you can’t extend that object and turn it into a method X that computes the same value lazily, it changes the type of the class.III) MAINSTREAM OO IS UNSAFE IN THE PRESENCE OF UNTRUSTED CODEThis is not an inherent object-oriented limitation (Object-Capability Security is a concept that fixes this[16]), but rather a problem with the implementation of mainstream OO languages.In those languages, arbitrary effects can happen anywhere AND every piece of code has access to everything in the system by default. Nothing prevents an untrusted piece of code in JavaScript, running under Node.js, from doing a “require(‘fs’)” call and delete arbitrary files from your HDD when you run innocent-looking code like “1 + foo”. Java mitigates this by providing some privilege verification with stack inspection[17], but it’s just nowhere near as effective as OCS, and adds significant overhead.Pure functional languages sidestep some of this problem by just forbidding any effects by default[18], so you know that effects can only happen in certain contexts, and with a good effects system you know exactly which effects can happen in that context. Of course, impure languages (most FP ones) still have the same problem OO languages do.IV) DESIGN AND SINGLE-DISPATCHConsider an operation as simple as “2 + 4”. In object orientation, “+” is required to be a method, and “2” and “4” must be arguments of this method. Should this method live on the object 2 or on the object 4? How should “2 + “foo”” be handled?Kay has discussed a bit of this in The Early History of Smalltalk[19]. Does it really make sense to think of numbers as objects and common mathematical operations as sending messages to an object? The conclusion was more that doing so enabled a kind of generic programming (where “+” could be overloaded in a simple way), so it was something you had to accept.There’s one major problem with single-dispatch (where one object owns the task of responding to messages exclusively): asymmetry[20], in which code like “a + b” may execute an entirely different operation than “b + a”, because “a” and “b” are different objects. Double-dispatch only alleviates the problem, multiple-dispatch solves it, but at the cost of being much harder to optimise, and making reasoning about dispatch behaviour much harder as well[21], in particular if you include subtyping.Another problem with one object owning the method is deciding where operations should go. Should it be “number.toString()” or “string.fromNumber(number)”? Both require each data structure to know about possibly internal details of each other, which is not ideal.V) INHERITANCE IS TOO COMPLEXIt’s very common for object-oriented systems to include some kind of inheritance, which is then used for code reuse. One of the major problems here is that inheritance must be a preserving subtype relationship. That is, if you inherit from class A, then class A’ must have all of the exact same behaviours A had, plus some more. You can’t remove or change things. Allowing people to override definitions leads to problems[22][23]!Another problem with inheritance is its power: single inheritance is not powerful enough to solve most of the complex “reuse” problems, requiring people to pack much more than needed into a single class or object. Multiple inheritance works as a composition mechanism, but leads to ambiguous dispatch rules that tend to be solved in ways that are harder to predict[24], in particular when these can be changed dynamically[25].Mixins tend to be a better solution for reuse, but they still suffer from lack of predictability, and conflict resolution is inexistent in the model. Traits[26]solve the problems with mixins by providing symmetric composition operators, but they are not really implemented in any language.VI) BETTER OO SYSTEMS REQUIRE SIGNIFICANT INVESTMENTHighly dynamic systems, such as Pharo[27], Squeak[28], Self[29], etc. solve many of the problems and limitations in Object-Oriented languages with specialised tooling. This integrated development environment (not to be confused with what “IDE” means in industry) is extremely powerful for working with object systems[30], but in order to really benefit from this power you have to reject all of the tools you know and are used to from your OS.You don’t use files, instead you modify objects directly in memory, and the system serialises your actions; There’s no Git, instead you use an integrated version control system developed specifically for changes in objects; There’s no terminal, instead you have a live scratchpad where you can try things; etc.This is a significant investment for those who are starting to use these systems, because they won’t really be that productive until they learn all of these new tools, and it’s also a significant investment for people who are implementing these systems, because they have to reinvent all of these tools that already exist outside of the walled garden, such as Git or the terminal.The image format many Smalltalk-like environments use is also it’s great blessing and its great curse[31].VII) OO LANGUAGES TEND TO BE BAD AT CONCURRENCYThis is not a problem of the OO model. Far from it. Remember that this is the model that influenced most of the late research on Actors[32], and was in turn greatly influenced by early research on it. Rather, it’s a problem with how most Object-Oriented languages are implemented[33].In our usual mainstream languages, we don’t really use objects for concurrency. Instead, we use shared memory! This is a terrible idea, results in programs that are usually more sequential to be on the safe side (aggressive synchronisation where it’s not necessary), or programs that simply try to go for optimal concurrency and end up with data races.Functional programming avoids a lot of these problems by favouring pure functions, and sometimes by not having an enforced order of execution. This allows compilers to do a lot of great optimisations for you, plus it makes data races impossible by design.Pony[34] is an exciting object-oriented language here, but it’s definitely not mainstream. Incidentally, Erlang[35]and Elixir are also exciting, but far from what most people would consider object-oriented. At least Kay seems to think that Erlang got part of the original Smalltalk vision right[36].VIII) TYPE SYSTEMS FOR OO LANGUAGES ARE TOO COMPLEXSubtyping relationships are complicated, and invariant functions are much easier to understand — some object-oriented languages that use subtyping allow unsound types to make things easier for users[37]. Row polymorphism tends to be easier to understand[38], and avoids some of the problems with loss of information with subtypes. We’re still studying how to infer good types in the presence of subtyping[39], and even then we’re still at a loss for how to provide good error messages for inferred types — what this means in practice is that the programmer needs to have a deeper understanding of the subtyping rules and provide explicit types in more places.Functional programming languages tend to avoid subtyping, so for most things it’s easier for developers with less knowledge of type theory to understand how types work in functional programs. This is, of course, not true with more static functional languages moving towards very sophisticated typing features, and closer to dependent types. But things like higher-kinds and GADTs don’t tend to appear as a fundamental feature as much outside of Haskell, whereas subtyping is very pervasive in Object-Oriented languages.Another problem with static verification of object-oriented languages is that many of the features considered as “core” features by some OO programmers are too dynamic to allow simple type systems. Things like Aliens[40], Mirrors[41], “becomes:”, changing shapes at runtime, and friends can’t be given types in most type systems. You either give up on static typing entirely (which is what languages closer to the Smalltalk philosophy do), or you add dependent types, which require significant effort to prove to the type system that your usage of these features is sound — though types that are derived from runtime values unknown to the compiler are still a problem.CONCLUSION(things eventually come to an end. Even my answers :’>)Object-Oriented programming has many flaws, and many of these are inherent in the models-as-we-know it. Some later models (AOP, COP, etc) fixes some of these flaws, but bring their own costs in understanding the code, which is not that great. New concepts (like Traits) alleviate some of these flaws, but lack implementations and sometimes impose additional overhead.Other models really just have different kinds of problems (although FP in particular seems to be doing better in the modularity, safety, and concurrency aspect). It doesn’t seem that a fundamental model for computations that is actually usable for larger programs, though Out of the Tar Pit[42] argues for a relational one instead of an object-oriented one.Footnotes[1] http://homepages.inf.ed.ac.uk/wadler/papers/expression/expression.txt[2] http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures[3] http://wiki.c2.com/?AdapterPattern[4] Lambda the Ultimate[5] Ruby (programming language) - Wikipedia[6] Extension Methods (C# Programming Guide)[7] The Swift Programming Language (Swift 4): Protocols[8] http://wiki.c2.com/?MultiMethods[9] Type classes: confluence, coherence and global uniqueness[10] Modular typeclasses · Issue #1886 · purescript/purescript[11] Aspect Oriented Programming: Radical Research in Modularity[12] http://homepages.ecs.vuw.ac.nz/~servetto/Fool2014/FundationForObjectAspectAndContextOrientedProgramming[13] The Implicit Calculus[14] Heap bugs with Order · Issue #1236 · scalaz/scalaz[15] siren-lang/siren[16] Towards a Unified Approach to Access Control and Concurrency Control[17] http://sip.cs.princeton.edu/pub/oakland98.pdf[18] Quildreen Motta's answer to How should one use side effects in functional programming if pure FP is excluding using side effects?[19] The Early History Of Smalltalk[20] Object-Oriented Multi-Methods in Cecil[21] Type Checking Modular Multiple Dispatch with Parametric Polymorphism and Multiple Inheritance[22] http://wiki.c2.com/?CircleAndEllipseProblem[23] Quildreen Motta's answer to Which languages have a solution to the circle-ellipse problem in OOP?[24] C3 linearization - Wikipedia[25] http://www.cs.cmu.edu/~aldrich/papers/ecoop05pmd.pdf[26] Traits - Composable Units of Behavior[27] Pharo - Welcome to Pharo![28] Squeak/Smalltalk[29] Self | Welcome[30] Choosing Smalltalk On Porpoise – Smalltalk Talk – Medium[31] quil_ebooks on Twitter[32] History of Actors[33] Quildreen Motta's answer to Is there a more powerful tool for multithreading than synchronized blocks in Java?[34] Pony - Pony[35] Erlang Programming Language[36] Joe Armstrong & Alan Kay - Joe Armstrong interviews Alan Kay[37] Type Compatibility[38] Quildreen Motta's answer to Object-Oriented Programming: What is a concise definition of polymorphism?[39] Polymorphism, subtyping and type inference in MLsub[40] Unidentified Foreign Objects (UFOs)[41] Through the Looking Glass Darkly[42] http://curtclifton.net/papers/MoseleyMarks06a.pdf