Interesting to hear your experience. I had read a good amount about Eiffel and also large parts of Bertrand Meyer's book Object-Oriented Software Construction (quite a thick book too, and which uses the syntax and semantics of Eiffel, or something close to it, IIRC [1]), some years ago. Had found the language very interesting and also was impressed by it (and by the book). Read some case studies / success stories about it, which were good too. He and his team seem to have taken a lot of pains and thought a lot about the design as well as implementation of the language, from both an academic…
The best description of exceptions that I've seen is Bertrand Meyer's exposition of them in _Object Oriented Software Construction_. His definition depends on the notion of Design by Contract. An exception is an event that causes a function/method to fail because it is unable to satisfy its contract. The caller is then responsible for cleaning things up (so it can satisfy its contract) or it also triggers an exception resulting it its failure. In the context of Design by Contract, the list of things that can cause an exception include: * hardware/OS errors * calling a method on a null…
Design by contract is good. I've used it in some projects. https://en.wikipedia.org/wiki/Design_by_contract I first came across it when I was reading Bertrand Meyer's book, Object-oriented Software Construction. https://en.wikipedia.org/wiki/Object-Oriented_Software_Const... From the start of the article: [ Object-Oriented Software Construction, also called OOSC, is a book by Bertrand Meyer, widely considered a foundational text of object-oriented programming.[citation needed] The first edition was published in 1988; the second edition, extensively revised and expanded (more than 1300…
Actually, there's a very elegant solution to the diamond problem. Eiffel does this with a renaming mechanism. Martin Odersky certainly knew about Eiffel's solution when he designed Scala, but my guess is that, he chose the simpler solution of traits, just like most languages, because general multiple inheritance just isn't too useful. Still, it's a shame that most people interested in programming languages have never heard about Eiffel, or ever read the superb book "Object-Oriented Software Construction" by Eiffel's creator, Bertrand Meyer. Eiffel has many flaws (the most proeminent being…
> What's the advantage of invariants over unit testing? I studied Eiffel in university under Bertrand Meyer, and here's his (probably unique) point of view. If someone hands you their library code and their unit tests, you have to understand their unit tests - which involves understanding why they chose the values that they did. There's also nothing stopping someone from testing the internals of their library as opposed to the publicly exposed behavior. With contracts, imagine that to understand their library, you only see the method declarations with accompanying contracts. You don't see…
Eiffel is considered by some people to be one of the better programming languages (maybe even near the top of the heap, though of course a lot depends on application area you are using it for, just as with any other language). Features in it may have influenced other languages. Not sure, but I think Design by Contract is one of them - preconditions, postconditions and invariants, which can be implemented somewhat, using assertions, in languages that provide assertions. But Eiffel provides language support for them. Search for some Eiffel success stories. There was one very good one - I don't…
Like most articles on "Inheritance" this is clueless about providing any "real meaning/understanding". People always take the soundbites (eg. Uncle Bob SOLID) provided as a mnemonic as being the end-all, don't fully understand the nuances and then usually arrive at a wrong conclusion. LSP (https://en.wikipedia.org/wiki/Liskov_substitution_principle) has to do with behavioural subtyping guaranteeing semantic interoperability between types in a hierarchy. It involves not just the syntax of function signatures but their semantic meaning involving Variance/Invariance/Covariance/Contravariance…
There is no confusion if you understand that Inheritance is just a "mechanism" to express three (and maybe more) different kinds of "policies" and a single class may implement any or all of them in which case it becomes important to disambiguate which methods/functions express which "policies". There is a abstract concept and a syntactical expression of that concept which needs to be clear in one's mind. Again, asserts are just the "mechanism" to express pre/post/inv "policies" in code. Without having an understanding of pre/post/inv from the pov of Hoare Logic, merely using asserts will not…
Bertrand Meyer's [1] book, Object-Oriented Software Construction [2], mentioned in another comment here, is good, IMO; some people consider it a classic. I had read large parts of it some years ago. He is the creator of the Eiffel programming language [3], which seem really good (I tried it out, some, using EiffelStudio, his company's main product - it also has a GUI libary for creating GUI apps, at least on Windows where I tried it, and can make EXEs, also has a possibly unique notion of freezing and melting, IIRC, related to compilation), though unfortunately Eiffel does not seem to have…
That's EiffelStudio's Melting Ice stuff [1]. One of Bertrand Meyer's trademarks is his penchant for coming up with funny names for such features. (Edit: Reading over it again, I realize that this may be read as criticism. To clarify, while I disagree with Meyer on some things, this isn't about disagreement. He is a teacher at heart – in fact, a very good teacher – and you can see some of his habits for keeping students engaged sometimes carry over into his writing.) You don't see this approach really anymore, because these days it's so cheap to just generated unoptimized native code if…