Dalija Prasnikar

16 hours ago, dummzeuch said:

It could be an option to have a (restricted access) repository somewere with the RTL/VCL code where "the community" collects patches for everybody to use.

But that poses several questions:

• Which versions of the RTL/VCL are maintained there? Only ever the latest one? But what about people who are stuck with older versions for whatever reason?
• What about forward- and backporting fixes if multple RTL/VCL versions are maintained?
• Who maintains it? This/ese person(s) would be the gate keeper(s) to proposed patches.
• Who grants / revokes access and on which criteria? Is every Delphi customer allowed access, even if he only ever bought Delphi 1? Or is it restricted to the version(s) he bought? How does he prove that?
• Even if only the latest RTL/VCL is maintained, what about the .x.y Delphi releases? These are of lately only available to customers with subscription.

I think that could be quickly become a nightmare for the maintainer(s), not just the technical issues, but even more the legal issues.

Valid questions...

• Embarcadero would have to appoint gatekeepers - probably their employees, although here they could use knowledgeable community members, but again those community members would have to report back to Embarcadero.
• For every point release maintaining interface compatibility is imperative. So there would have to be stable interface compatible version branch, and unstable interface breaking branch for future point release. 
• From previous points, it is clear that only current release would be maintained. Any back-porting would have to be done by Embarcadero respecting older release interface compatibility. Probably very few (and more critical patches) would be applied to older versions and only few releases back (maybe even just one - depending on the point release frequency)
• Access rights - once you put code out it is hard to revoke access, and maybe it would make little sense for doing so. As far as initial access rights are concerned - while it would be nice if everyone could have access, realistically it only makes sense to give access to people that have current (or one older) release. You have to have means to contribute and if you are sitting on Delphi version that dates 5 years ago, you cannot contribute in meaningful manner to current and future releases.

I know that people would love to have fixes for older versions, but I don't think amount of effort needed for such back porting would be sustainable. At least not for Embarcadero. What community in general could do in that regard - I don't want to speculate (including legal reasoning) At the end even now, we all have the sources, and nothing prevents people to organize some dark web code patching.

4 hours ago, AlekXL said:

(Emphases are mine) Not-so-thinly-veiled sabotage of my motion! Too long, too expensive, too bad, too expensive again, too soon...

After some time, I have no doubt you'll politely and wisely concede: too late

I am not sabotaging anything. I am merely presenting the facts that must be taken into account. Without that it may look like open sourcing the compiler is just one GitHub click away and Embarcadero is not doing that "good" move on purpose because <insert conspiracy theory du jpur>

Also, when it comes to sabotaging, like I already said, you don't need any help in that area, you are perfectly doing that yourself. 

Your request lacks any real arguments and is basically insult to everyone working at Embarcadero.

11 hours ago, AlekXL said:

So maintaining 1 expert "gatekeeper" is problem to EMBT? Some Russian or Chinese guy, who wouldn't ask more that 2-3 grand a month, working remotedly? If yes, then EMBT should close their RAD business, not wasting our time.

And before you ask, the gatekeeper would have time to catch up, before pull request would become non-stop, and contributors would teach him basics for free.

 

Seriously???? You would leave five year old alone in control of the house when parents are away? Actually, it would be more like leaving the five year old with matches and can of gasoline.

Let me say it again: Somebody (Embarcadero employee), extremely knowledgeable in particular code base would have to be gatekeeper - managing pull requests and communicating with community in general.

That somebody would have to be top gun compiler engineer, someone from existing team who knows code base well, not someone who would they just throw in working for peanuts. So yes, under current circumstances that would take valuable resources away from current compiler development. And that is something we (or Embarcadero) cannot afford at this time. 

Yes, it would be good if Embarcadero would expand their core teams. That would be good move regardless of open sourcing . But even if they manage to hire good engineers today, it would still take quite some time before such expanded team could bear the burden of open sourcing.

11 hours ago, AlekXL said:

System.pas is part of RTL, good luck compiling it with wrong compiler version! Have you ever dare to recompile it?

As for FMX, old RAD versions users would love to have FMX bugs fixed for free, and damn the EULA.. Who would delve into which version of FMX is actually compiled into your app?

Your advice would ruin the company. Well done.

LOL

And leaving amateurs to rampage all over the compiler, yeah, that would end really well.

As far as RTL/VCL/FMX is concerned, it is not about catering for all old versions in existence out there. It is about going forward, so no compiler version would not pose a problem.

2 hours ago, Markus Kinzler said:

The sources of the libraries are already "visible" for customers.

Yes, but sometimes it takes several iterations for some fix, or needed feature to end up in release. And patching on your own takes time. If everyone has to do it that is huge waste of time. 

My comment under the QP request that explains my stance on the matter. I don't want to enter into endless discussion there because it is ultimately the wrong place.

@Marco Cantu enabling access to compiler (or any other sources) and allowing community contributions does not mean giving it for free. You can put up any license terms you want. I know that enforcing license is harder than having closed source, but people that will violate such licenses will just use cracked versions anyway - that is far simpler that rebuilding compiler on their own, only handful of developers would go that route.

While Delphi compiler code might be worth studying for those interested in compilers, I highly doubt there is any ground breaking technology there worth stealing nowadays. From that perspective opening compiler (or other sources) does not seem like showstopper.

@All however, open sourcing (I will use that term, regardless of what the actual licensing model would be) is not as simple as mere dumping source on GitHub. Somebody (Embarcadero employee), extremely knowledgeable in particular codebase would have to be gatekeeper - managing pull requests and communicating with community in general. 

In order to open sourcing to be successful endeavor there must be significant number of contributions made, without that - the whole thing makes no sense for Embarcadero (and for the community as well - beyond satisfying everyone's curiosity). In that case gatekeeper(s) will have their hands full. Not to mention that for every successful contribution, there will be countess others that will have to be reviewed and rejected for various reasons. That part introduces additional cost to Embarcadero and ability to develop code on their own, because part of the resources that would be used to developing in house will have to be spent for community interaction. 

Eventually, gains from community code can outweigh the costs, but that would take some time. Also, in code base that large, it may take years for community to start contributing in meaningful manner. And gate keeping would have to start immediately. There will be developers that will jump in from the start trying to fix their pet pevee without looking at bigger picture (breaking things like bull in a china shop).

Now, that might look like - it it would take long time, let's start early then... but like I said, initial cost in terms of resources might be too high. Especially, now when there is a lot of work to do on various compilers - new ones (Android and macOS 64bit), including introducing some new features that are already in the works.

From that perspective, open sourcing compiler in general... yes, but I don't think now (or any time soon) would be the right time.

Right now (or soon enough), opening up sources to RTL/VCL/FMX would be much better move - we already have the sources, we already know our way around them. Community at large can more successfully contribute to those sources than to the compiler. Again, that kind of project would also have some initial cost, but I believe it could pay off much sooner.

Open sourcing is the double edged sword - in order to be successful it takes resources that would otherwise be spent on in house development (with much higher initial progress rate). But the push for open sourcing (because, of the illusion that community can fix things faster and better) is greater in times when internal resources are spread thin, than in the times when everything works peachy. So it is kind of damned if you do damned if you don't situation.

54 minutes ago, Jacek Laskowski said:

I tried with overload, but it did not help.

http://docwiki.embarcadero.com/RADStudio/Rio/en/Methods_(Delphi)

Overload is used when you have methods with same name but different parameters.

Override is used when you have methods with same name and same parameters, but one is in parent class (marked as virtual or dynamic) and other is in child class and you want to override method functionality in child class.

30 minutes ago, AlekXL said:

Neither. "For they have sown the wind, and they shall reap the whirlwind", Hosea 8:7. You were quite critical about my demeanour, well, you always reap more than you've sown. Nature's law, God's Word, uncontestable anyway.

I am critical, because you are seeking collaboration and your attitude is making more harm than good. Not just for your particular request, but it is undermining other efforts in similar areas. I am not stranger to saying harsh words, but there is a difference between backing your words with actual arguments and empty phrases like "we love Delphi more than you do".

Feel free to criticize me when I do something wrong. I have no problem with that. 

I am an atheist and God has no meaning to me. For my actions I will be and I am accountable in this life only.

27 minutes ago, AlekXL said:

old news. Best news is inline variables and deprecating ARC.

It does not matter how old it is, it matters that things can change . 

Just like deprecating ARC at some point seemed highly unlikely. And for the record that is the change I didn't wished for.

7 hours ago, Joseph MItzen said:

And others could tell you stories of the issues that have been closed as "won't fix" or "by design". I remember Dalija Prasnikar got Marco to re-open several that he'd closed in the past (as far as I know they never actually got fixed though).

Baby steps 

If bug report is open, it does have greater chances for being fixed than if it is closed. Also not all bugs are easily fixable.

But one of the greatest issues, that for long period seemed like it will never happen, was introducing 8bit strings to all platforms. If nothing else, this makes me hopeful.

9 hours ago, AlekXL said:

 

Ok, I've just checked. And must say, this is officially a lie (were you a rookie, I would call it mistake, but you're prominent, trusted member of the community, so take it)

 

Swig fork of Delphi is able to import C++ class -> Delphi class wrapped, through dll import.

Swig generates c++ proxy *.cxx from a header, and even able to specialize C++ template class (you need to write something like TEMPLATE_WRAP0(vector ,vecint,  int );

Swig flattens said class members to in the *.cxx and export this through __declspec(dllexport) (or statically, but delphi-swig cannot handle static linking)

Then, Swig generates pas stub , which imports flattened methods(stupidly, it does not add underscores to names, but this is easy fixed by

__DLLNAME name '  ==> __DLLNAME name '_ "replace all"

Additionally (default, but optional), Swig adds Delphi class wrapper, for the C++ class/specialized template class.

I've just regenerated, and compiled template example, from example.h example.i , with C++Builder and Delphi.. This example is simplistic, so I don't know how it would work it with complex c++ classes, but considering SWIG is serious tool, we can hope.

And here your splendid personality jumps out again. Yes, I made a mistake. People do that, you know, regardless of experience. After being knowledgeable in your field of work, ability to recognize and admit your own mistakes is one of important qualities for successful developers. If one is not able to own his own mistakes it is hard to expect that such person will allow others to make mistakes without making too much fuss about it. Your response shows that either you don't have that quality or you have really short fuse. And neither makes you a wonderful team mate.

And If you read my response you will see that I didn't included SWIG library (two and some years old) - I simply overlooked it. Last time I had to use C++ with Delphi was 8 years ago and it was no fun. I am glad that landscape has changed in that regard.

Delphi ecosystem is not huge (no matter how much we would want it to be), and ability to interact with libraries written in other languages can make a whole world of difference. You don't want to reinvent hot water if it is already out there. Also, you might use other toolsets besides Delphi and utilizing same libraries across those toolsets also counts a great deal.

34 minutes ago, AlekXL said:

To get bugs fixed? Code generation improved? I dont dream that Delphi compiler will soon be completely free, I just want it to be better

Serious question. So far you have managed to volunteer other people to do the compiler fixing.

But you haven't told us anything about what can you offer in that regard? How can you help improving and fixing the compiler? What are your skills?

10 minutes ago, AlekXL said:

please clarify, those tools edwinyzh mentioned is unable bind to C++ class? 

 

First tool explicitly mentions it is not for translating C++ header files

Another excellent tool which utilize CLang to convert C (not C++) header files to Delphi:  https://github.com/neslib/Chet

Second tool description says This tool will convert most of your standard C code.

So, yes C, no C++. 

For using C++ you need to go extra mile: http://rvelthuis.de/articles/articles-cppobjs.html

10 minutes ago, AlekXL said:

Oh, that's nice.. Looks like Joseph Mitzen exaggerated poor condition of C++/Delphi linkage? All those 5 pages of discussion worth that single post..

 

Just for the record C is not C++. Joseph Mitzen didn't exaggerated that.

28 minutes ago, AlekXL said:

Lars, just please don't sabotage the discussion and the cause, will you?

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.

On 3/20/2019 at 3:02 PM, Uwe Raabe said:

Are people still using that old component pallet? 

Yep.

13 minutes ago, RDPasqua said:

before Delphi fail, buy Island LLVM from RemObjects, they have already a Delphi RTL compatible. Bind VCL and or FMX over it and have all OS, all platforms, clean, fast, perfect code.

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

11 minutes ago, David Heffernan said:

That's surely not a problem with LLVM per se, rather the Delphi compiler on top of LLVM?

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.

23 minutes ago, Markus Kinzler said:

But this was the "old-gen" compiler beeing subsituted for most of the targets now. Only the Win32 and OS32 compilers are based on it.

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

27 minutes ago, Stefan Glienke said:

IDE tooling does not work properly and some of it completely stops,

Also inline variables of a managed type are not always properly initialized.

 

As much as I like this feature syntax wise - I would stay away from it for now 😞

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)

On 3/28/2019 at 8:14 PM, edwinyzh said:

Inheritance for extension is Ok, but for code reuse? Maybe not that good.

 

Although I have achieved code reuse with class inheritance, but from time to time I feel unwanted class coupling were introduced too.

 

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. 

16 hours ago, edwinyzh said:

Let me reiterate  it - need not to say, both inheritance and composition have their own application situations, there is no doubt about it.

 

The point is, to simply put, always consider composition first before you inheriting a class, if both can do the job, prefer composition over inheritance. 

 

That's all about the point.

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. 

51 minutes ago, edwinyzh said:

Do you know the circle-ellipse problem? That's the problem of inheritance. 

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.

15 minutes ago, edwinyzh said:

You miss the 'code reuse' part of the original question.

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.

30 minutes ago, Anders Melander said:

@Dalija Prasnikar I agree with your characterization but in some cases I find that composition is better suited than inheritance even though inheritance would be more natural. For example if I were to create a list of TSomething it would be tempting to use TList<T> as a base class, Problem is that it might give me too much. If I only need an Add method, a Count and an array property, then composition is probably better (I guess one could call it inheritance through composition).

I've seen too many examples of inheritance (not just from TList) where most of the inherited methods doesn't make any sense and would break the application if used.

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. 

35 minutes ago, edwinyzh said:

@Dalija Prasnikar I'd like to add two things:

1. I believe you are talking about implementation inheritance but not interface inheritance.
2. The common mistake to make when using implementation inheritance is creating God Object.

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.