[fpc-pascal] Fwd: What to do to get new users

[Nikolay Nikolov]

On 10/18/24 11:41 AM, Karoly Balogh via fpc-pascal wrote:
> Hi,
>
> On Thu, 17 Oct 2024, Michael Van Canneyt via fpc-pascal wrote:
>
>> By contrast, Pascal is not designed with GC in mind.
>> You'd need to redesign the language.
>>
>> If you do that, you can throw away all existing code if you introduce GC,
>> because the two concepts do not merge easily.
>>
>> Embarcadero tried it in Delphi, and they failed. Not surprisingly,
>> they removed again all automatic memory management.
> Maybe it was mentioned in the thread, I just glanced through it, but how
> about ARC (Automatic Reference Counting), Objective C style? To be honest,
> I really liked that, and we already have it kind of in place for strings,
> even temporary strings and maybe even temporary arrays created inside a
> function. We'd just need to extend it for a bunch of other things, I
> suppose. Manual FreeAndNil() is the ugliest part of Object Pascal for me
> for sure... OTOH, for Object Pascal you might end up with RAII in this
> case, instead of ARC, because how how the language works. I did not like
> it that much in C++, but maybe because modern C++ syntax is properly
> horrid...
>
> But anyway, that concept replaces GC for a majority of use cases, and I
> really liked it for the couple of years I've been doing iOS stuff. But of
> course Apple adopted it for all the underlying classes too, which points
> back to the fact, that modern languages are usually a thin wrappers around
> some library concept, and if your library API is as full of legacy and as
> inherently messy as ours, there's little you can do.

Reference counting already exists, if all your objects are accessed 
through interfaces. Then you just inherit from TInterfacedObject and 
you're good. I used this approach in PTCPas and it works well. I wonder 
why it's not used more often.

There are also advanced records, which support implementing reference 
counted smart pointers, RAII-style objects, etc. It's just that there 
are not ready made implementations in the standard library. However, the 
language already supports them. I used advanced records for the Unicode 
support for the video unit, to implement TEnhancedVideoCell in a way 
that conserves memory, by overlaying a WideChar and a WideString. Since 
most graphemes are represented by a single Unicode code point, that 
falls in the BMP, it fits in a single WideChar, so there's no need to 
allocate extra memory on the heap for a WideString. However, to support 
all languages, we need to support graphemes, represented by a sequence 
of code points (e.g. non-BMP characters, combining characters), so for 
them, a WideString is allocated on the heap. See the implementation in 
videoh.inc and video.inc, if you're curious. This means we have all the 
power of C++ objects, without the ugly parts (no multiple inheritance of 
classes and the "diamond" problem).

Btw, I usually don't mind calling FreeAndNil() myself, most of the time, 
objects have a clear ownership, so an object creates the objects it owns 
in the constructor, and destroys them in the destructor. For the more 
complicated cases, there are the options, mentioned above. I've used 
them very few times, but when I needed them, they were there.

> For once, I'd be really glad if a bunch of the containers would be
> Thread-Safe by default, like TList and things, and they aren't, because
> they're based on almost 3 decade old Delphi concepts, when multithreading
> wasn't as big of a deal as these days. No amount of "lets add GC" would
> fix this. (And I know we have thread-safe alternatives, but they aren't
> used everywhere and consistently. So when using a bunch of libraries, you
> still end up managing thread-safety by hand...)

More modern container libraries, using generics, RAII, or whatever else 
are always a good idea, but AFAIK there are already some decent TList 
alternatives in the RTL and packages (fgl, rtl-generics)? It's just a 
matter of learning about them and getting used to using them.

I think we should start using more modern (generics-based) containers 
inside the compiler sources itself, but that's another story, that only 
concerns compiler developers, not users. :)

Nikolay