Dalija Prasnikar

Agreed. There is no need for others to sabotage anything. You are perfectly capable of sabotaging both the proposal and this discussion on your own.

Yep.

Without going into deep discussion about compatibility and other technical issues... AFAIK Marc Hoffman would rather drop dead than sell anything to Embarcadero...

Core issue is in LLVM https://bugs.llvm.org/show_bug.cgi?id=1269 While in theory it would be possible to address this issue from Delphi side, it is probably as hard as solving it on LLVM side for the similar reasons. The most prominent issue is in capturing exceptions raised from accessing nil references, and addressing this particular use case would probably be simpler than all encompassing solution. However, I am not in position to say how easy or hard would be to implement this kind of fix in Delphi compiler.

No. Only iOS and Android are LLVM based. http://docwiki.embarcadero.com/RADStudio/Rio/en/Delphi_Toolchains AFAIK first Linux release (Tokyo) was also LLVM. And you don't want to have LLVM on other platforms for few reasons. Not only it is slower than "old" handcrafted Delphi compiler, more importantly LLVM cannot handle exceptions in way Delphi compiler does. Using LLVM on desktop would break a whole a lot of code. You can fin more at https://dalijap.blogspot.com/2018/10/catch-me-if-you-can.html

If everyone stays away, bugs will never be found and fixed... I have used them a lot in various shorter and longer experimental code... so far so good (in spite known bugs)

Another thing... you are asking confirmation for some design approach that didn't feel right at the end. If it does not feel right, there is probably something wrong and it is quite likely that composition would be better choice. If composition solved your problem, probably it IS the right choice and the next time you encounter similar situation it will probably be right choice again. But, without seeing actual code and knowing the context in which it will be used, it is really impossible for us to say one way or the other.

Err.... No... You started with prefer, now you have come to always... and you are conditioning yourself to use composition without considering inheritance... you should consider both at the same time. There are always trade offs and you have to take those into account. If you start with composition and say, OK composition can solve this problem, I am all done, at some point you will make wrong choice because sometimes inheritance will be better fit. Now, I could be wrong, I don't know what is in your head... The more skill one has.. the easier is to decide... Sometimes you will just take a glimpse on some problem and you will immediately know what is the proper solution... but just because you are able to decide fast, that does not mean that you didn't fully considered all consequences of particular solution. Again, while rules help you have to be careful with the rules. They cannot save you from thinking and using the best tool for the job. I don't know how many times I used inheritance over composition or vice versa, I am not counting... it is irrelevant... even if 90% of the time composition is better, that still leaves you with 10% where it is not.

It is problem with bad inheritance. Like I previously said, if you take narrow approach and only focus on Circle IS specialized case of Ellipse, you are bound to make a mistake. Even more so, if you lock particular behavior in base class that cannot be universally applied to all sub-classes.

No I didn't miss it. But code reuse is separate matter. It is not a primary drive. Code reuse plays significant part in OOP design - you don't want to unnecessarily repeat code, but you also don't want to make your choices solely based on code reuse. Whatever you do, you always must look at the problem from many different aspects and all basic OOP principles. If you take too narrow approach, you will most likely make wrong choice. Sometimes, answer to inheritance vs composition for code reuse is neither, because doing one or the other can result in monstrosity. Sometimes, repeating two lines of code and keeping things simple is more viable approach. So back to your question and original article - "If it's only about code resue" Answer depends on how you interpret the question... it is never ONLY about code reuse... but if reusing some lines of code IS the only reason to use inheritance, then you are probably doing that part wrong... at the same time composition in such case can also be wrong choice. Depends what is the purpose of that code and its function. If you cannot clearly define its responsibility then you are bound to go wrong with composition, too.

That is why there are no clean and absolute rules. You have to decide what makes sense in each particular case. Sometimes creating wrapper classes that will expose only valid functionality makes sense, sometimes list is just a list.

Interfaces don't have implementation, so if you want to reuse code you either have to use class inheritance or you must use composition. IS-A and HAS-A rule can help you determine whether inheritance makes sense in a first place. If IS-A rule is satisfied, then you have to see whether in that particular case you should use class inheritance or composition. When it comes to creating God objects, they break other OO principles. Composition is preferred - problem with that approach and your original question "Prefer composition over inheritance for code reuse?" is that people tend to interpret it like NEVER use inheritance. And then they go down the different rabbit hole.

Not exactly... there are slight differences in behavior. Not that this part matters when you are choosing between inheritance and composition (as general term)

It always depends on particular situation. Both composition and inheritance have their place. Sometimes you can use either, sometimes there is a clear distinction. Some tips that can help you decide. IS-A - inheritance - Sword IS-A Weapon so Sword should inherit Weapon HAS-A - composition or aggregation - Unit HAS-A Weapon so Unit can be composed with Weapon object With simple classes that satisfy IS-A condition plain inheritance will do. With more complex classes, you may want to use composition or delegate some behavior to other classes, especially if that behavior can be reused independently. Delegation - delegate behavior to another class when it is not an objects responsibility to implement behavior on its own Composition - when object is gone the composed objects are also gone - when Pizza is gone so are the ingredients Aggregation - class is used as a part of another class, but still exists outside that other class - when Unit dies Weapon still exists

That change was not worth while even back then. You had two variants for Seek and it was very easy to use wrong one. If you used 32 bit one on streams that support 64 bit your code would only work for streams smaller than 2GB. Change didn't affected older code, but it had permanent negative effect on new code. I encountered such bugs myself, and also have seen others bumping into it on numerous occasions. Yes, at the end our code was at fault, but it was really easy mistake to make. There was several bug reports around that issue at the time in old Quality Central.

YES, backward compatibility matters. But in cases where backward compatibility causes more trouble down the road, then it is not worth the price. In this case, maintaining backward compatibility also opened TStream and descendant classes to subtle bugs when working with streams larger than 2GB.

If your Note 8 has Oreo 8.0 OS then debugging does not work because Google screwed up on OS level. You need to update OS to 8.1 that fixes the issue. It was not something EMBT could fix. http://blog.marcocantu.com/blog/2017-december-delphi-android81-debugging.html

To some extent theming has a purpose because without it you could not have dark theme. Problem here is that Delphi (VCL Styles) based theming is just horrible since day one (even before it was introduced in IDE). Instead of VCL Styles being fixed and then used at large, EMBT choose to use VCL Styles without fixing issues. Another problem is not that just in theming itself, but revamping Options dialog layouts without making proper alignment/size adjustments - so everything visually just falls apart.

var [weak] fib: TFunc<integer,int64>; Marking it as weak breaks the cycle. However, there was a bug with weak that is only recently fixed (not sure whether in 10.3 or 10.3.1)

Error Insight has always been Error Inside. It never worked properly, and was always lagging behind.

If only making good examples would be so simple.... it is so much easier to trash other people's examples... Joking aside... bad examples (or ambiguous examples) can make more damage than good. OOP is complex matter and not always straightforward. Ask 100 experts about it and you will get 100 different answers. My rule of thumb is learn about OOP, design patterns, testing and then apply common sense over it. If some rules collide, then apply KISS (Keep it simple, stupid) and YAGNI (You aren't gonna need it) and DRY (Don't repeat yourself) before any other principles. If it seems too convoluted or you don't have clear understanding why... better don't use it than use it in a wrong way. That does not mean people should not strive to learning and understanding better practices. In that context, primary goal of encapsulation is protecting implementation details that can change to avoid subsequent changes in consumer code. When you write your own classes you are the boss, you can decide what is implementation detail and what is not. Of course, you have to be careful about those decisions because you will have to live with them for a long time. When you consume other people's classes you must avoid using things that are not part of public API. Since it is not always possible to hide all implementation details, it is possible that not everything that is publicly accessible is really part of documented public API. Unless public API is clearly documented, sometimes it can be hard to know what is implementation detail, and what is not. Experience can help, but it is hard to give any good general tips on the matter - it all depends on the actual code. And this is where original question came from - what is implementation detail in some code and why is better to use some construct comparing to another. Another thing to keep in mind is that OOP depend on the language. What fits in one, does not fit well in another. In Java encapsulation means having geter and setter methods for everything accessible - because Java does not have properties. If you expose field directly any changes in access logic that has to go through geter or setter will require changes in consumer code - because Java expects parens () when you access method. In Delphi you might as well start with directly exposed field... changing that into property will not change consumer code (unless you add read or write restrictions) and adding geter or setter methods will also have no direct impact on consumer code. Of course, most Delphi developers will use properties instead of directly exposing fields, but this is more of common practice than actual requirement for fields that will be publicly accessible - part of the public API. I could probably go on for days... but I have other things to do... 🙂

Sorry, but you started going off rails saying that you should not use fabc.ToString for displaying integer value as text, thus blowing the whole encapsulation and hiding the implementation thing out of proportion. Now, it is possible that you just used poor example and that you actually tried to say something completely different. I am not trying to shred concepts to pieces, I am just trying to show their usage must be balanced. Abusing the concepts to the point of absurdity is as bad as not using them at all. What better example to show how not everything can be absolutely hidden and protected than to show that strings itself are leaking their implementation details.

I found something... not mine.... actually, the original thoughts on leaky abstractions https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/

No. It was not about leaking strings, rather Delphi strings leaking their implementation details like character size, encoding... Think about going from TP fixed size string implementation to pre-Unicode Delphi string implementation to Unicode Delphi string implementation. I remember writing about it, but don't remember where...

I cannot find it either... I don't think it was a blog post... maybe some post on G+ or somewhere else...