Leaderboard

I was already working on my event bus when I discovered DEB. I would still work on mine even if I knew about DEB sooner, because I also wrote about it in my book and I cannot reason about other people's thought process It is also published as part of book code examples, but it is a feature that deserves separate repository not tied to the book. When it comes to why DEB would not fit my purpose (if I ignore the book part), is that it has more complicated code and more features that don't necessarily bring anything of value to me (for instance, using attributes for setting subscriptions), but on the other hand have big impact on performance. My even bus also supports all types as messages, so there is additional performance boost and avoiding unnecessary memory allocations when message fits into integer or small record type. And at last, my even bus has waitable subscription, so you can wait that all dispatched messages are being fully processed. This is critical feature for more complex cleanup scenarios - yes, it can also be achieved through other means, but it is easier when it is built in feature, and I use it a lot. And the most personal reason is that my code is more compatible (similar setup and calls) with my old thread-unsafe observer framework, and I can more easily and gradually refactor old code to using new one.

The inline variable in question will be of type TCar as its type will be inferred from type used in constructor: TCar. In such code where object instances are reference counted, you will need to explicitly specify correct type: ICar because reference counted instances need to be stored in interface references for proper initialization of reference counting mechanism. var car: ICar := TCar.Create;

Main problem wit ChatGPT is that if you are asking about something you don't know well, it can lead you in completely wrong direction and you will never know it because you lack the expertise. And it will lead you there with a confidence of a master. And it is not wrong only occasionally, it is wrong most of the time. If you like wasting your time on wrong leads and hints, then it is absolutely the right tool for any job.

This is a forum for solving problems for other developers. Your answer does not solve the question that was asked. Posting wrong answers only serves to confuse developers that might come across them

People quoting ChatGPT, in the style of "according to Wikipedia", is getting really tiresome. And as could be expected, some people have also begun using it in discussions to pretend knowledge about topics. Just like they do with Wikipedia. Ask a follow-up question that requires actual knowledge and their arguments fall apart. ChatGPT "knows" language and that's it. It has zero "understanding" of the topics. It has no awareness. It doesn't understand logic or philosophy, nor even know what that is. This isn't a science fiction movie.

I'd love an AI that would suggest improvements to the code that I write, instead of writing the code for me.

I already checked. Domains where it might work better are in a creative domain where there are no right or wrong answers, but then it is just a parrot that repeats someone's thoughts. When people talk about AI they like to focus on intelligence. But ChatGPT is just a language model, with some corrective mechanisms on top. What it means? It means there is no intelligence involved. It is just fancy "text completion" model that uses probability to determine which word should follow next in some sentence. Even when the model grows, and its probability analysis improves, it is still just dumb "text completion" It will never be able to reason about what it writes. And again, it may get better in avoiding ridiculous mistakes, but you are still stuck with original issue: you cannot trust the information it gives you, because it may not be correct and you will not be in position to realize that.

I don't think so. The Turing test is pointless unless your only goal is to create something that can fool a human and what good is that? We don't need a computer to do that. Trying to define intelligence with too narrow parameters like "it talks like a human" or "it is self-aware" is also not helpful. Intelligence, as observed in most humans and many animals, is many different things the sum of which is what we think of as "intelligence". The ability to talk like a human, using a database of human knowledge, is really just a party trick and largely irrelevant with regard to Strong AI. I wonder what will happen when the AI chatbots have generated so much output that they predominantly use their own, not necessarily correct, answers as training data...

Yes, I do. I expect the compiler to optimise out unnecessary assignments. If it's supposed to be immutable, the record will have private fields and a public constructor you will have to use. Adding a new field to a record later will cause it to be uninitialised, unless you hunt down every instance in your code and add an assignment for the new field manually. Unfortunately, the Delphi compiler isn't even able to emit a warning when an uninitialised record field is used or returned. program Project1; type TRecord = record b: Byte; end; function getRecord(): TRecord; begin // end; var r: TRecord; begin r := getRecord(); WriteLn(r.b); readln; end.

I have published initial release of NX Horizon Event Bus for Delphi as Open Source on GitHub. Features: implements the publish/subscribe pattern, decoupling publishers and subscribers events are categorized by type any Delphi type can be used as an event supports four types of event delivery: synchronous, asynchronous, synchronous in the context of the main thread, and asynchronous in the context of the main thread provides generic record and reference-counted class wrappers for easier usage and management of existing types as events simple in both implementation and usage fast full thread safety https://github.com/dalijap/nx-horizon

When I use records, it is exceedingly rare that they are left unfilled with actual values for very long, so I would tend NOT to initialize.

It depends. If I'm going to initialise every field I wouldn't default initialise. Many of my records have class methods named New that don't default initialise and assign to each field. I wouldn't want to offer blanket advice. Default initialise if you need to default initialise.

I used Default on record maybe once or twice. On the other side I rarely have a chance to use records. Nowdays it's almost always a class I am working with. Generally speaking, when it's important for readability I do like to initialize a variable/field/record just to have a cleare code when I have to revisit it.

var client := TRESTClient.Create('https://<API server host>/auth/oauth2/token'); try var request := TRESTRequest.Create(nil); try request.Client := client; request.Accept := '*/*'; request.AddBody( '{' + '"client_id": "013C1A93-3D33-4986-8A7C-773D02C26214",' + '"client_secret": "FE8FBA46-6ABF-4DF1-8D5E-31345DAAD194",' + '"grant_type": "client_credentials"' + '}', TRESTContentType.ctAPPLICATION_JSON); request.Execute; var response := request.Response; if response.Status.Success then HandleResponse(response.Content); // this has to be implemented by yourself finally request.Free; end; finally client.Free; end;

Yes, it is doable, but the syntax is slightly different than you showed. The inner function has to be defined before the 'begin' of the outer function, eg: function foobar(param1, param2: string): string; var somevar: string; function inside(Param3: string): string; var anothervar: string; Begin Do something with Param3; ... Result := anothervar; end; begin Somevar := inside(somestring); Result := Somevar; end; This is covered in Embarcadero's documentation: Nested Routines