While fixing http://bugs.freepascal.org/view.php?id=13619, Jonas did not apply neither code cleanup not comment fix parts of it.

Are such changes not wanted?
I did not made a separate patch for them -- should I? I thought they are trivial and obvious.

On a more generic note -- will massive code reformatting patches be accepted? Like, e.g. changing keywords to lower case?
And, more importantly, changing class/function names to CamelCase?

Alexander Klenin wrote

While fixing http://bugs.freepascal.org/view.php?id=13619, Jonas did not apply neither code cleanup not comment fix parts of it.

It's mainly because I saw the patch only after I already looked up the Delphi declaration and fixed the code myself. I didn't consider the other changes that important to revert my changes, apply yours and then run the testsuite again. I did intend to manually apply the Playthingies -> Miscelaneous change manually, but somehow forgot about it. I'll do it now.

Are such changes not wanted? I did not made a separate patch for them -- should I?

No, that's generally not necessary.

On a more generic note -- will massive code reformatting patches be accepted?

I'm not sure. But if they should be done, now would probably be a good time given that merging from trunk to fixes is already fairly hard anyway (at least for the compiler), and I don't really see a 2.2.6 happening (although I'm sure other developers disagree with the latter).

Like, e.g. changing keywords to lower case? And, more importantly, changing class/function names to CamelCase?

There's no real standard in FPC regarding the casing of class/function names. Some files use camel case, others lowercase, and a few Java- style (first character lower case, rest camel case). I personally prefer lowercase these days.

Jonas

In our previous episode, Jonas Maebe said:

(I don't think the situation with 2.2.6 changed from the one with 2.2.4. I don't see a 2.4 release within the year happening. And a 2.2.6 with only library fixes is better than no release for over an year (*) )

There's no real standard in FPC regarding the casing of class/function names. Some files use camel case, others lowercase, and a few Java- style (first character lower case, rest camel case). I personally prefer lowercase these days.

I don't care much about reformattings either. As long as the block structure is readable, which is also the only case I would like an exception: some codebases don't put begin on a newline. Ugh.

(*) And that's a planning year. So the usual release delays excluded.

Marco van de Voort wrote

(I don't think the situation with 2.2.6 changed from the one with 2.2.4. I don't see a 2.4 release within the year happening.

I don't see what the problem is with stabilising/releasing 2.4 as it is. If generics and Delphi 2009-style ansistrings are not going to get finished any time soon, why not release 2.4 without them being finalised? There are plenty of other improvements and changes. And the longer we wait with releasing it,
a) the more time spent on merging (and discussing merges) b) the bigger the changes will be for the end users and the harder it will be to adapt programs
c) the harder it is for end users to test programs against it and to find all errors before the release
d) the harder it is for us to stabilise it before the release (because more changes -> more potential bugs)

Jonas

In our previous episode, Jonas Maebe said:

Well, Lazarus is currently amassing large handcoded UTF8 ansistring codebases, something I don't think that is healthy. If unicode is postponed to the next major release, it will be long, very long before this is cleaned up.

How far do you think we are from releasing 2.4 then? Maybe plan an alpha release to see where we stand?

There is some sense in that yes. Still, I keep getting the feeling then that we don't deliver on the 2.4 promises then, and worse that the early 2.4 delays the impotant features more than that it helps bring them to users faster.

Coming from someone who is very insistent on bugfree implementation and proper testing - and rightly so - this sounds very strange.

As far as I know, there are still fundamental implementation problems with generics, and as long as they are not fixed, I wouldn't want to see it released.

Michael.

I insist on that for stuff I implement myself and for stuff merged to fixes. I'd very much like that to be also the case for all new functionality implemented by other people, but if I insisted on that I'd probably either leave or drive almost everyone else away.

As far as I know, there are still fundamental implementation problems with generics, and as long as they are not fixed, I wouldn't want to see it released.

They have already been released, twice. They would of course keep their beta monicker. I'm as much in favour as anyone of having them fixed, but if no one works on fixing them, should we never release trunk anymore because the generics haven't been finished?

Jonas

Waiting with releasing 2.4 and spending time on 2.2.x fixes releases (instead of on a 2.4 release) is not going to speed up the implementation of full unicode support either.

How far do you think we are from releasing 2.4 then? Maybe plan an alpha release to see where we stand?

I'm not aware of any big problems with 2.4 at this point (relative to 2.2.4, or in general, except for what has been mentioned). As far as I'm concerned, it would be perfectly fine to split off a 2.4 branch today, and to release a first beta. I don't know what the situation is regarding the database components though (and maybe other things with which I have little to do).

I think it is simply a bad idea to promise things before the work has been done. None of us can predict on what they will work or how much time they will have. As far as I am concerned, we should simply release when the result is stable (as in: no regressions since the previous release, so the new FPC release will be better than the previous one -- bar any missed bugs of course) and a certain amount of changes have been made (how many/which depends on the nature of the changes, the situation, external factors, etc).

Jonas

In our previous episode, Jonas Maebe said:

Why I don't entirely agree with that (major releases are simply more widely spaced because their scope was constantly upscaled in the past), I do see the problem that there is currently nobody working on the strings and generics. So waiting an year might not change the in short: you convinced me.

(I thought btw, generics in 2.2.4 had improved to being more or less usable?)

I don't see problems too from my viewpoint. But I don't know db components too. Maybe we should ask the lazarus people if there are "hot" items.

I don't know. While that sounds safer, letting stuff forever in limbo just creates a lot of insecurities about direction, and that might be worse than an occasional broken or postponed promise.

Marco van de Voort wrote

(I thought btw, generics in 2.2.4 had improved to being more or less usable?)

A number of important bugs were indeed fixed. But as far as I know, several more are left.

Jonas

BTW, is generics good enough to be used in e.g. math.pp? I am in process of re-formatting it now, and the amount of duplicate code is staggering.

I see no problem if a certain feature has still some bugs. Just look at the linux kernel: ext4 was for years experimental.

While I don't like this either, it's how OSS works after all.

Alexander Klenin wrote

BTW, is generics good enough to be used in e.g. math.pp?

Afaik, generics have only been implemented for classes until now. Plain generic functions are not (yet) supported.

Jonas