Parent and Owner are what they say they are.
Owner: the TComponent that "owns" the TComponent-descendant. In other words, that is responsible for the lifecycle of that instance. Parent: the control on which the control is visualised.

It is not because by default the LCL or VCL don't keep those in sync in most cases, that it is redundant. I've seen plenty in my 10+ Delphi years of code where a control is created by another TComponent and where the parent is set to a control on a(nother) Tform or container.

Whether or not that is good design in all cases is not the issue. The point is that they do not need to be the same. (as well as Parent can be a container)

I then conclude from your case above, Graeme, that fpgui does not work with containers like TPanel/TGroupbox/... and does not allow to "inject" extra visual controls on another form?

kind regards,
Dimitri Smits

Op 2010-06-04 02:02, Dimitri Smits het geskryf:

I know what they are and what each does. I'm simply saying you don't need to properties for that. A Parent can just as easily manage the lifespan of it's chidren as the Owner can. We have listed many such examples in LCL and VCL already. fpGUI proves this too.

It is not because by default the LCL or VCL don't keep those in sync in most cases, that it is redundant. I've seen plenty in my 10+ Delphi

The most common example normally thrown at me is that docking will not work if Owner and Parent is always the same. Well, they are wrong. A rudementy docking implementation using fpGUI once again works just fine (under Linux and Windows). You simply reparent - which also transfers the ownership (lifespan control) to the new parent/container component.

I then conclude from your case above, Graeme, that fpgui does not work with containers like TPanel/TGroupbox/... and does not allow to "inject" extra visual controls on another form?

And there you are wrong. fpGUI supports all that.

But now this message thread is getting off-topic. My question wasn't about Parent or Owner, it was why doesn't TWriter output the whole hierarchy of components when I give it the top level parent (a Form). I think I got my answer, but that simply raised the point that it's a stupid design (that's how I see it at least). But as with most things I suggest, it will not be changed, even if it is a flawed design. Borland and Embarcadero jumps off the cliff - FPC must now also jump off the cliff. :)

Regards,
- Graeme -

Borland and Embarcadero jumps off the cliff - FPC must now also jump off the cliff. :)

Hello, Graeme!

I'm surprised of this, fpc still systematically trying to follow Delphi, after so many years. I can understand that at the beginning the fpc team needed to mostly comply with Delphi, as de facto object pascal standard. But then, fpc could live its own life, possibly taking the best of Delphi's innovations, but not having as main goal to be always running after it. Fpc anyway has done different choices for some features (including choices of non-implementation), so why not having already made the step of declaring fpc a (object) Pascal dialect of its own?

[Note: if ever this topic is a sensible one launching flame wars, just close it. This is not my intention, I'm just asking.]

Denis
________________________________

vit esse estrany ☣

spir.wikidot.com

Op 2010-06-04 12:54, spir het geskryf:

(including choices of non-implementation), so why not having already made the step of declaring fpc a (object) Pascal dialect of its own?

I agree 100%. It was all good and well (in the beginning) to try and be a Delphi clone, but now it makes no real sense to me. FPC (or Lazarus IDE or Lazarus LCL) will never, ever be 100% compatible with Delphi. You will also never be able to simply swap out delphi and replace it with FPC and recompile. Developers will always have to go through a porting process - a fact of life. And if FPC's only goal is to be a Delphi clone, then soon they are going to be out of business - why? Because Embarcadero is already working on a cross-platform compiler (the biggest advantage FPC has(had) over Delphi) and a 64-bit compiler. Embedded systems will be the only advantage FPC then has over Delphi - and this is a small percentage of FPC users.

But we all know, many others will disagree with us - saying that staying a clone and always one step behind is good. :)

Regards,
- Graeme -

To many people inside and outside the FPC team, a high degree of Delphi compatibility is a must. For a simple reason: reuse of existing Delphi code, of which there is infinitely more than FPC code.

Do not forget that component creators must maintain their code for older version of delphi. That means that they cannot use the 'newer' features of Delphi anyway and so they don't mind if we don't have all of the latest. And usage shows that there still is a very large amount of D7 out there, so it's unlikely to change anytime soon.

And to be honest, I think we do a very good job of it. Yes, we don't have 100% compatibility. But no, it's never 100%. But it is certainly good enough to satisfy most people that need it.

Michael.

And to be honest, I think we do a very good job of it. Yes, we don't have 100% compatibility. But no, it's never 100%. But it is certainly good enough to satisfy most people that need it.

Hello, Michael!

No doubt about this. And I take the opportunity to thank you (and all others) for this great (and huge) project. What I question is the necessity to keep Delphi-compliance now and for ever. And the consequent choice of _not_ making, progressively, a free (object) Pascal dialect, with its own design & principles, style & taste, and so on... (*) Sure, I also understand the great advantage of reusing Delphi code and cloning its libraries, esp. for production code. But after so long, fpc could already have a relevant shared codebase, don't you think? (what by the way GNU PAscal does not have). How old is freepascal already, 10 years?

Denis

(*) For instance, I have had a look at GNU Pascal, and via this look discovered standard & extended Pascal design. I must say that on numerous points it looks better to me than TP & Delphi choices; standards were obviously very carefully designed. An FP freed of Delphi chains could take the best of this. "Free" also means free ;-) Another point is the terrible library/unit mess, partially inherited from Borland pascal history, partially increased by compiler modes. Very hard to find what one looks for (except maybe if coming from BP). More or less, anything can hide anywhere; and there are variants of any feature; and many are just legacy from the 80's. (I don't even evoke the global namespace.) Severe, radical, cleanup needed, imo. ________________________________

vit esse estrany ☣

spir.wikidot.com

In our previous episode, Michael Van Canneyt said:

To many people inside and outside the FPC team, a high degree of Delphi compatibility is a must. For a simple reason: reuse of existing Delphi code, of which there is infinitely more than FPC code.

(see e.g. also the number of Delphi compatibility bugs reported. This is quite a high percentage)

And porting 3rd party delphi code.

And to be honest, I think we do a very good job of it. Yes, we don't have 100% compatibility. But no, it's never 100%. But it is certainly good enough to satisfy most people that need it.

Yes. THat is also the big flaw in Graeme's reasoning. The fact that porting will never be 100% perfect is no reason to abandon the possibility completely.

This is very visible in 1.0.x vs 2.x. With 1.0.x usage of Delphi code was very low, with 2.x it is much, much higher.

A lot of it are relative benign things. But a lot of benign things make porting large codebases difficult.

More. 15-16 years.

There is no global namespace; there is a per-unit namespace if you care to use it. It existed before the term namespace was coined.

But, and this is the main thing:

The call for Delphi compatibility is MUCH larger than the call for ISO or Extended ISO pascal.

If someone were to submit patches to improve the ISO-Pascal compatibility: no problem, they would be accepted. Once upon a time, we had a gpc mode (which is pretty much what ISO pascal is), but there is no demand for it, so it died a quiet death.

Theorizing is nice, but sterile if no-one uses it in practice.

And in view of the large Delphi codebase: I think Borland didn't do such a bad job of it.

Personally, I fail to understand what people are complaining about. I make my programs with the tools available, and they work damn well.

Michael.

Marco van de Voort wrote

And porting 3rd party delphi code.

I've already ported OS/2 Pascal, C#, Java and C/C++ code to Free Pascal. It's not that hard at all, so even if FPC is not very Delphi compatible, porting will still be much easier than porting from other languages.

What annoys me most is that there is no clear cut line between portability and improvements. Sometimes the FPC core developers all all ok with improvements, and sometimes flatout refuse even minor improvement (at which point they throw the Delphi Compatibility card). It's like mood swings. If we catch you guys on a good day, then things go smooth - but dare we propose something on a bad day, then all hell breaks loose.

The other problem with Delphi Compatibility is that not even the FPC team knows which version of Delphi we are supposed to be Delphi compatible with. First TP, then D5, then D7, then a bit from D2007, another bit from D2009 oh, and then this other little bit from D2010. Oh, and we even have a bit of Kylix in the mix. Compatibility with Delphi is drastically declining, but still no improved design or other goods ideas are allowed (most of the time). How long are we supposed to wait until you guys finally give up the compatibility race, and see how flawed (and broken) it is at this current point in time?

Op 2010-06-04 14:09, Michael Van Canneyt het geskryf:

Personally, I fail to understand what people are complaining about. I make my programs with the tools available, and they work damn well.

Michael, the thing is that sometimes somebody will come up with a better idea for something - yes we can sometimes think of better ideas/designs than Borland, Embarcadero or Microsoft. They are just developers like we are!

But take a simple idea like adding Observer support to the RTL. If you didn't support that idea, and only I proposed it.... And if we had to go through the same arguments as before, the simple answer would have been that NO it will not be added. EVEN though it will not break any existing code. Then on top of that, you get people proposing stupid ideas like implementing your own RTL simply to add one little feature.

Yes the Observer issue got resolved (hopefully), but such arguments really discourages a developer from outside the core team to propose something in the future. Why must we always struggle with proposals - fighting an uphill battle all the way. Some of us don't give a toss about Delphi compatibility (we are programmers, we can work around such problems), and yet proposals get refused even if it doesn't break Delphi compatibility (simply because Delphi doesn't have that feature to start with), or we caught the core team on a bad day. In the end the FPC project suffers because it couldn't improve as quickly as some of use would have liked, or those developers move on to something else.

Regards,
- Graeme -

Of course we do: as recent as practically feasible, given time.

And yes, we are aware that this is a moving target. If we didn't have this approach, we'd be stuck with TP compatibility, and we'd have a very small community indeed.

The compatibility race will never be given up; if you are waiting for that, you will be disappointed.

But you can submit patches. Very few patches have been refused till now.

Michael.

Each idea is taken on its merit. And rest assured: core people must sometimes struggle equally hard. It is a price we pay for stability. It is guarded like a hen guards her pullets..

That there is discussion is a necessity. It takes only 2 people for that.

In 15 years of FPC development, I have known only 2 such discussions. I can live with that.

Yes, I was not fond of Foreach (I think it's an unneeded construct). I was even less fond of generics. But both made it in the compiler. So no, we're not closed. Each idea is taken on its merit, we take into account many things. If our viewpoint is different from the proposers', we see other (or less) things. But in the end we decide, because we end up doing the work. Implementation is the small part. Maintenance takes a lot of work.

And as for 'improve quickly':
- Where are the donations ?
- Where are the developers ?
As soon as someone pays me my salary to work full-time on FPC: there will be REAL quick improvement; I guarantee it.

Till that time: FPC is a *hobby* project for all core developers. Many have wives and children. We have never left any doubt on this.

As it is, the users cannot even get a foundation organized which would coordinate development. I have offered many times to act as a go-between.

But nothing ever comes of it, so: get organized !

Michael.

The other problem with Delphi Compatibility is that not even the FPC team knows which version of Delphi we are supposed to be Delphi compatible with.

Of course we know: given infinite time, we would support all. Given the limited time we have, we support the stuff we think being important. If you think something else is important: submit a patch like Paul did with the foreach stuff or Alexander Klenin's student with the case <string> of stuff. Of course, a patch breaking existing stuff will be accepted less likely.

Oh, and we even have a bit of Kylix in the mix. Compatibility with Delphi is drastically declining, but still no improved design or other goods ideas are allowed (most of the time).

Most current Delphi code still compiles. Very little code uses the new features.

In our previous episode, Graeme Geldenhuys said:

Maybe. But the point is that a lot of users think it is more important to really minimize that.

Well, situations where there is a possible conflict always requires a comparison of both arguments. That is always a bit subjective. That's why there usually are always several devels in such discussions.

The other problem with Delphi Compatibility is that not even the FPC team knows which version of Delphi we are supposed to be Delphi compatible with.

That's a moving target.

First TP, then D5, then D7, then a bit from D2007,

(1.0.x Delphi mode was aimed at D2-d3, and inbetween there), but keep in mind that is over say 13 years. (17 if you count the TP-only years). Logically also the user base changed versions over such periods.

Compatibility with Delphi is drastically declining,

I've not even a clue what you mean with that. IMHO it is still vastly improving.

but still no improved design or other goods ideas are allowed (most of the time).

That is awfully subjective. And I don't agree.

How long are we supposed to wait until you guys finally give up the compatibility race, and see how flawed (and broken) it is at this current point in time?

I don't see a change coming there. I've learned to never exclude anything long term though.

Btw, you are not the first to have such feelings and arguments. I was the same roughly in the period '98-'02 (e.g. I was very opposed to many D4+ features being implemented). The same with the multi platform angle (being very opposed to Kylix too, due to its Linuxisms)

This disappeared when I got more experience in Delphi (and the reasons behind these features), and when I had a couple of years of bugfixing under the belt (which causes you to be confronted with earlier, in retrospect, bad decisions)

I'm still not fond of Kylix though. Both deviating of the VCL and the extreme linux/x86 centricity made it IMHO a "worst of both worlds". However it was canned before it could be cleaned up.

Op 2010-06-04 14:58, Michael Van Canneyt het geskryf:

I have many things I would like to work on. Unicode being on the top of my list. My employer already approved the time I can spend of it (after our current project release, which now seems to have moved to Jan/Feb)

Till that time: FPC is a *hobby* project for all core developers.

That's the problem. To others it's a vital part of making a living - where it is used in a commercial environment. I put my job on the line when I suggested our company switch from Delphi to FPC. And if it is just a "hobby" to the core developers, why then so damn strict with accepting improvements (patches, alternative designs etc)?

Regards,
- Graeme -

In our previous episode, Graeme Geldenhuys said:

And if it is just a "hobby" to the core developers, why then so damn strict with accepting improvements (patches, alternative designs etc)?

Hobby doesn't mean we don't care. And it doesn't eliminate a decade (and longer) experience in development, fixing bugs etc. Even if only in parttime.

Op 2010-06-04 15:45, Florian Klaempfl het geskryf:

of stuff. Of course, a patch breaking existing stuff will be accepted less likely.

And yet Embarcadero is ok with breaking compatibility - if it means improving the product. Yet core developers from FPC and its "hobby project" can't get over that hurdle??

Regards,
- Graeme -

In our previous episode, Graeme Geldenhuys said:

Sure. If all devels agree that it is an improvement and necessary.

We have always been very clear about that it is a hobby. I can show you all the mails that were sent carrying exactly that message.

I put my job on the line when I suggested our company switch from Delphi to FPC. And if it is just a "hobby" to the core developers, why then so damn strict with accepting improvements (patches, alternative designs etc)?

Because we care about FPC and it's features & stability. We are proud of it.

I care about my hobby. I care more for my hobby than for my current day job; So yes, I am strict. I want it to be better than e.g. what I we had put in all crazy suggestions we got through the years without caring, I don't think we would stand where we are today. But we didn't. And all that exactly because we care and have clear goals.

And let's be correct: if we did crazy things, would you have 'put your job on the line' ? I don't think so. It is exactly because we are so strict, that we can offer something which people can trust and rely on.

So actually, currently it's you being dangerous, and we are protecting your job safety. Just because we like our hobby.

Now, isn't that cool ? :-)

Michael.

That is also the reason I am still working with 2 million lines because they broke compatibility is NOT funny, and will - in all likelihood - cost us a lot of money.

Michael.

You might judge on what's improving fpc and what not if you break the border of 500 resolved fpc bug reports. Then you know what average users really want (and not only the criers on mailing lists). The bug tracker is full with examples like: http://bugs.freepascal.org/view.php?id=16618

Hello,

This discussion is interesting, but it's a meta-discussion that is overwhelming this list due to its sheer volume. So let's please move it to the fpc-other list.

Thanks,

Jonas
FPC mailing lists admin

>