Leaderboard

Two things: 1. I really try my best to avoid negations in booleans 2. I try to name methods that do stuff like verbs and where possible put the parameter in context of the name Hence processOrder(aUseWidget: Boolean) { if aUseWidget then { processOrderWithWidget(); } else { processOrderWithoutWidget(); } } And SetControlsEnabled; // Implicit True SetControlsEnabled(True); // Explicit SetControlsEnabled(False);

There are two problems with using Boolean parameters. First, is when like in Nick's example you are literally calling two separate functions to do something based on boolean parameter. If there is common logic shared inside the method, where making two distinct methods would violate DRY principle, then it is fine to have parameter that will make your method do two things. Another problem using Boolean parameters, when you have valid reason to make method do two things is that boolean on its own is very rarely descriptive. EnableDisableControls(True); Does the above call enable or disable controls? If you need to make method do two things, it is better to use enum with two values that will give you more descriptive code on the call site. In your example if the method would be called EnableControls, then using Boolean parameter would be self descriptive. It is pretty obvious what following line does: EnableControls(True); On the other hand boolean in following method makes code unreadable ListFiles(const APath: string; IncludeSubFolders: Boolean) Can you tell what following code does, unless you know ListFiles declaration by heart? ListFiles(Path, True); In such case enum, is much better option even though it would have only two states. ListFiles(Path, optIncludeSubFolders);

Nick's point is fine. I think you just misunderstood it to mean that you needed to replace all boolean args. Following somebody else's recipe without really grasping the issue won't make your code any better. It will just give you work to do and make it likely that you will introduce bugs to your code? If you don't have comprehensive tests for all of your code then you are in big danger of that.

Use some judgement. You don't need to get rid of all booleans. Code like: SetControlsEnabled(True); SetMenusEnabled(True); SetFeaturesEnabled(True); is perfectly fine. Does it make sense when you read it? Yes, of course it does. What you need to watch out for is code like: EnumerateFrogs(True); Nobody reading that can infer what the argument does.

Apart from the braces I don't see a problem with that example. It's a convenience or wrapper function and while it's not clear from the context the function doesn't appear to do two completely different things based on the value. A kitten dies every time you do that. Remember that anyone reading the code that uses the function will have no idea that the parameter name makes the intent clear. EnableDisableControls(True); // WTH? EnableDisableControls(False); // WTF?

*YAAAWWWN* with GzipFile(fileobj=output_file, mode='wt', compresslevel=9) as gzip_out: gzip_out.write(contents) Sounds like a rule from the one thousand fifty nine thing where Delphi still sucks blog.

Millions of lines of code keep me tethered to Delphi. My employer is paying for it, but the lack of viable alternatives keeps us here, bugs or not. Yet, I predict there is .NET projects eating into my schedule in my near future. I.e. a fresh, new set of bugs to learn to work around.

That was indeed my initial intention. However, the more I tried to remove what I considered obsolete code, the more problems I encountered as I found what seemed obsolete was still used by other parts of the library. For example TCustomBitmap32 has 14 different Line methods, 7 LineTo methods, 7 HorzLine methods and 7 VertLine methods. That really is excessive and IMHO should be removed and intead use the separate and much more flexible polygon renderer (in GR32_VPR). I'd disagree with Anders on that, though of course I could still greatly improve Image32's design. It's fair to say the TImage32 class that's at the core of my Image32 library does have a large number of methods related to loading and saving images, as well as a number of image manipulation methods (including hue adjustment and basic afine transformations - scale, rotate etc). But most of these methods (or similar) also appear in Graphic32's TBitmap32 class. IMHO Graphic32's TBitmap32 is much more monolithic, as it containing a whole host of line rendering methods (as mentioned above) and text (polygon) rendering methods too. These really shouldn't be there, as these operations are much better served by the functions found in Graphic32's Gr32_VPR unit. Further, TBitmap32's line rendering methods will only draw 1 pixel wide lines which is extremely limiting. So I would argue that my TImage32 class is much less monolithic than the TBitmap32 class. Almost none of my Image32 libray uses code from Graphics32. The excepion to that is a small amount of code in my Image32_Draw unit where the polygon renderer uses a memory allocation technique I copied from Mattias Andersson's Gr32_VPR unit. (When comparing Image32 rendering performance with Graphics32, I couldn't figure out how Mattias' rendering was so efficient.) Nevertheless my polygon renderer is based on https://nothings.org/gamedev/rasterize , though it still isn't quite as fast as Mattias' renderer. I did also briefly copy Projective Transform code from the Graphics32 library (with attribution), but that was replaced some time ago with my own code adapted from some more flexible JavaScript code I found here https://math.stackexchange.com/a/339033/384709 (again with attribution). With regard to which library is better, I suggest if you're familiar with Graphics32, or if polygon rendering performance is critical, then use Graphics32. However, Image32 does offer several benefits over Graphics32. It's a much simpler library to learn and use IMHO and it contains better cross-platform support with both Lazarus and FMX options.

As already stated in a different thread I have adapted the TimSort implementation for FreePascal I found on github to compile with Delphi 2007 (and probably earlier, but I haven't tried it). The source code is licensed under the Apache License 2.0 and available in my dzlib on OSDN. Note that this currently only sorts an array of integer and is still pretty rough. I'm going to refine quite a bit. There seem to be only 2 (now 2.5 😉 ) TimSort implementations in Pascal / Delphi available. (According to @David Heffernan there is also one in Spring4d.), but none that does not require generics.

If the caret in the Source-Code Editor is placed on the identifier of an existing component, for example: ...then an IDE command (e.g. "Select Component") should select this component in the Design Structure Panel (and in the Instances List of the Object Inspector). This would be VERY USEFUL! I kindly invite everybody to vote for this quality report: https://quality.embarcadero.com/browse/RSP-32108

There is no Tortoise folk. That are two totally different tribes that just picked the same name.

I think using verbs is better. //old way procedure runTimer(bRuntimer); timer.enabled := bRuntimer; // better two procedures Procedure Run timer.enabled := True; Procedure Stop timer.enabled := False; // later expand the functionality Procedure Step timer.enabled := False timer.timer // to walk through code // // Nick Hodges in his book says always program against an interface. I say always program against a 5 inch X 3 inch UX or 3 X 5 UI. Also consider this for codebase T: Boolean Inside procedure What T := T and B or A Doing this preserves the T incoming state. This latching allows T's state set elsewhere be used reducing the tests in What.

If a method does two diverse actions, define two methods. If a method performs an action which is something on/off or enabled/disabled then you can use a boolean, if the false/true statement is clearly defined by the naming of the method. If a method performs something, but with a custom behavior, don't use boolean (or booleans) but an enumeration or even better a set. It will be much more easy to understand what it does, without looking into the parameter names, and it will be more open to new options/behaviors. function TMyObject.SaveTo(json: boolean): string; // what is the behavior with json=false? function TMyObject.SaveToJson(expanded: boolean): string; // what does SaveToJson(true/false) mean without knowing the parameter name? function TMyObject.SaveToJson(expanded, usecache: boolean): string; // what does SaveToJson(true/false, true/false) mean without knowing the parameters names? type TMyObjectSaveToJsonOptions = set of (sjoExpanded, sjoUseCache); function TMyObject.SaveToJson(options: TMyObjectSaveToJsonOptions): string; // you understand what does SaveToJson([]) or SaveToJson([sjoExpanded]) or SaveToJson[sjoExpanded, sjoUserCache]) mean

Names mean nothing. You have to understand what people say, and judge it for yourself. Stop following people blindly based on reputation. Try to develop your own critical assessment of what you read.

Looks like someone forgot to notify Support that Embarcadero's community forums are now dead.

This makes no sense whatsoever.

There is a well known design flaw with passing arguments to const arguments. procedure Foo(const Bar: IMyInterface); .... Foo(TMyImplementingClass.Create); As we know, Foo won't increment the reference count because Bar is const. Possible issues are the object is leaked, or released early inside Foo (e.g. if something inside takes a reference and then releases it). This should be fixed by having the compiler realise at the call site that something needs to take a reference to the interface while the function is executing, and emitting the necessary code at the call site. I've given up hope that this will ever be fixed. On the other hand, perhaps I should be pleased that Idera consider itself to be one of the hottest companies around.

Two books that are gold for picking up good coding habits - even this long after they were written: Code Complete 2nd Edition by Steve McConnell Framework Design Guidelines by Krzysztof Cwalina & Brad Abrams (Third Edition)

For free? Oh no, I am paying for it! 🙂

This is nature of reference types. It is possible to modify their content. Only reference is passed as constant, not the actual content. Being confused about reference types and how they are passed to the procedures is not Delphi specific thing. For instance, Java passes all parameters as values, but in case of reference types (objects) that does not mean content of the object cannot be changed, unless it is made immutable through some other means (for instance, not having setter or similar methods that would mutate content). That causes two misconceptions, first. that objects references in Java are passed by reference, not by value and second that otherwise mutable objects cannot be changed inside method. Of course, comparing to Java, Delphi has many more parameter modifiers and that certainly complicates situation and possible variations.

If the internal pixel data format is the same (which I suspect they are), then you can wrap a TImage32 in a TBitmap32 via a Graphics32 memory backend. They will both be operating on the same block of pixel memory so take care if you resize the TImage32 while the TBitmap32 is associated with it. I don't think you can do it the other way round (wrap TBitmap32 in a TImage32) since TImage32 doesn't have a backend concept. Of course you can always copy the pixel data from one to the other, manipulate it and then copy it back, but that's not very efficient.

Hi Angus and welcome Well, if all you want is a hammer then all the other tools may indeed seem like bloat. The VPR polygon renderer and the line methods solve two different but similar problems. Remember that the purpose of Graphics32 is to do things as fast as possible. This means specialization over generalization. VPR is a generalized vector renderer that does many things reasonably well while the line methods does one single thing as fast as possible. That's why, instead of a single line method with a bunch of parameters, we have individual methods for vertical lines, horizontal lines and "other" lines. It's also why each of these methods are found in different variants each supporting different feature combinations: clipped or unclipped coordinates, transparency, anti alias or not, patterns, etc. And for different numeric types: integer, floating point or fixed precision. It's all about avoiding compromises that would hurt performance and give the user of Graphics32 control over the choices that have an impact on performance. Replacing the line methods with VPR would be like putting all-weather tires on a Formula 1 car. The MoveTo/LineTo methods, like their TCanvas counterparts, are purely high level convenience methods that will be superseded and can be removed once the TCanvas32 rewrite gets merged. But that's being blocked by the 2.0 non-release Interesting. It looks like it should be easy to adapt that algorithm to the Graphics32 transformation framework. I'll give it go and compare it to the existing one.

Solved. I am going to take myself out the back and beat myself over the head soundly with a piece of 2 x 4. The 'Caption' I was trying to get rid of was actually in the image. :-( Colour me red. :-( Thanks for your input. I will just slink away now.... Regards, Ian

The Graphics32 team First of all I'm not the maintainer of Graphics32. I'm just a contributor. I don't even have admin rights to the main repository. As far as I'm concerned the current project lead is @CWBudde1 but I'm not sure he agrees and he's also been largely absent in a long time. Of the remaining 4 members, micha137 hasn't contributed anything significant in a year and Michael Hansen, Mattias Andersson and Andre Beckedorf hasn't been active in a decade. https://github.com/graphics32/graphics32/graphs/contributors (I'm not sure how reliable that page is as I seem to be absent from it). Roadmap The last roadmap I know of was from 2012 (posted in the old graphics32 newsgroups) and concerned the "mythical version 2.0". Since then some of the items on the roadmap has been implemented, some has been superseded and some things not on the roadmap has been added. At present only the Graphics32 issue tracker at Github gives any indication of the direction the project might move. Lack of progress From my POW the inability to make a decision and actually release version 2.0, incomplete or not, has been one of the reasons why the project has stalled. For example the present version supports Delphi 7 and later which greatly limits what can be done - or what people are willing to do. A new version would drop support for ancient versions of Delphi and only support XE and later. In April 2019 it was decided, by Christian, Angus and I as far as I recall, that we should just release version 2.0 as-is. But again, without anyone to take the lead, nothing happened. In my opinion the greatest blow to Graphics32 was the complete loss of the Graphics32 community. This happened when the project was moved to Github and people stopped using the newsgroups. Github is great for managing the project but it's not a community platform. Without a community we're left with individual developers that might still have an interest in the project itself but soon burns out or simply isn't interested in developing in a void with no interaction with others or feedback from the users. Apart from the discussions and QAs, a big part of the old newsgroups was that people posted examples of what they did with Graphics32 and how they did it, extension libraries and graphic algorithm implementations. Luckily I still have an almost complete local copy of the newsgroups and it's still a great resource for inspiration, examples and solutions. Actually it seems the usenet server is still alive: nntp://news.graphics32.org Of course one needs a news client to access them and I'm probably one of the last people on earth to have one installed Image32 I have read the Image32 documentation and I think I've looked at the source once but beyond that I have little knowledge about the project. I would be very surprised if Angus didn't use the techniques used in Graphics32 as inspiration. Although I know he loves to write things from scratch I doubt that he doesn't use Graphics32 as a reference. Anyway, I can only guess. As far as I can see the "architecture" of Image32 is that there isn't one; While Graphics32 is an object oriented framework on top of some highly optimized low level routines, Image32 is more of a monolithic design - one class does everything. As far as I remember this dislike of OO was one of the reasons he wanted to write his own. Another was that he felt Graphics32 had become bloated. I don't agree but that's beside the point. Current state of the project As I see it the current version (i.e. head in the master branch) is stable. There are no grave issues and nothing technical that hinders future adoption of the library into new projects. The documentation has fallen behind and in a few places it is no longer correct. The examples aren't that great but at least they compile and do what they were written to do. The future As I'm just another contributor I can only speak to what I would like to see happen. Someone has to take the lead. It could be me but then I would have to stop contributing code. I can't do both. Also, although I do have opinions about how and what should be done my area of expertise is architecture and implementation. Get 2.0 released or simply abandon the idea of major release versions. As I said above before the 2.0 problem is resolved there will be little or no progress. Move the documentation into a wiki so we're actually able to maintain it. Currently it seems updating the documentation requires custom tools and I for one don't need the hassle of building, installing and maintaining some tool just to keep the docs up to date. It's hard enough to find the motivation to do so without that. Separate the examples from the showcases and write some (or a lot) of small, simple examples that demonstrate how to get started with Graphics32 and how to solve the most common tasks/problems. Even I hardly look at the current examples when I need to figure out how to do something as they are mostly too advanced or bury the relevant code in unrelated gimmicks. I can imagine that they must be undecipherable to a new user. Get rid of or repair the code contributed by cowboys. Some of the newer features of Graphics32 was contributed (and accepted) without regard for the fact that other people should be able to maintain it (for example if the author went awol or decided to work on another project instead). The code should be commented, the algorithms used should be documented, etc. Even if none of the above happens I think Graphics32 will be safe for the immediate future. It's a stable and fairly complete library and there are enough people and projects using it that someone else is bound to pick up the mantle if all the current contributors get hit by a bus.