Wow, thank you everyone for the comments! Here's a large answer:)
I also would remove the apologetic "reasonable", and refer to Pascal's "declare before usage" principle. ( I assume it is somewhere mentioned near the beginning).
I reworded and shortened this part a bit. Thanks:)
It was apologetic, because indeed other languages do not have this limitation --- e.g. in Java you also usually need to declare stuff before using it, and yet two classes, in two separate files, can freely use each other. In exchange, in Java you can easily get a run-time error if you don't recompile everything after changing some class. The compiler does not track dependencies, you decide what and when to recompile.
Clearly, the Pascal has advantages here, giving you a compilation that is fast and also guaranteed to be correct, with all identifier references checked at compile-time. But for this, we sacrifice the possibility of circular dependencies, and I felt it should be explained:)
Anyway, my clumsy reasoning in the document was probably not helpful here, so I shortened it.
Qualified identifier usage, and, related, type aliases. (type xx = unity.xx)
Good idea, thank you - I described both these things in new sections:
http://michalis.ii.uni.wroc.pl/~michalis/modern_pascal_introduction/modern_pascal_introduction.html#_qualifying_identifiers_with_unit_namehttp://michalis.ii.uni.wroc.pl/~michalis/modern_pascal_introduction/modern_pascal_introduction.html#_exposing_one_unit_identifiers_from_anotherFPC Reference Guide (topic about class operators) says that "is" operator can be used only on com interfaces!
There were some things that didn't work with CORBA interfaces in the past. With FPC 3.0.0 things just work, and I would focus on that:) The "is" and "as" operators work as expected on both COM and CORBA interfaces now. Since they are consistent with classes and wotk for both interface types now, I would advice just using them.
Note that for COM, you can also use the "Supports" function, but for CORBA the only way to check is to use "is" (as far as I know).
It seems that this part of the FPC documentation was simply not updated.
Or to put it into other words: i thought the record/advanced record chapter was a bit small and a bit tucked away.
That is deliberate indeed. I wanted to focus on our main concept, which is "class".
As mentioned, the document is directed at programmers, who usually already know what a "class" is from other programming languages. They know it from Java, C#, C++, Python... everybody has a "class" now:) That's why introducing an "intermediate" concept of a record did not seem necessary in my eyes.
So I treated the record types as "use only if you need to squeeze more performance / particular memory layout". That's also how e.g. structures are treated in C#, and that's also how I find most modern Pascal code looks like. (This is of course biased by my own code.) You use classes, for their flexibility, and think about records only when performance matters, when you really have lists of thousands of somethings.
If this was an introduction to the language for beginners (not people already familiar with the concept of "class"), I would possibly do it differently, more like you describe. Introducing records could be a nice "launching point" for the beginners indeed, to not burden them with the need to construct / destruct explicitly and all the extra class features.
It is a trap.
You make all your functions for string, and then you get a pchar and cannot use it with any of them
Better use only pchar for functions
Sorry, but I don't agree with this. The usual type to use for text in Pascal is "string" -- not "PChar". Functions that take and return "string" (usually equal to "AnsiString") are consistently introduced across RTL, FCL, LCL...
I definitely do not want to use PChar in all my functions, it would mean throwing away all the comfort that AnsiString brings.
And I prefer not even talking about PChar in this document -- as it is useful mainly for interfacing with libraries written in other languages. And you can, with some safety cautions (UniqueString etc.) convert AnsiString to PChar. That's one of the advantages of AnsiString. So you're not "locked" even if you used AnsiStrings in all your code.
The as and is operators also work on COM interfaces.
But it is a bad idea to use them
They are too slow
That's a too general statement, in my opinion.
Sure, it's good to avoid run-time checking with "is", and casting with "as". Not only faster, but also the code is safer. But it's not possible to avoid it entirely in real, large applications. That's why every OOP language has a syntax to check the class type, and perform a checked typecast to a descendant. This applies to both classes and interfaces.
You should not reject a useful language construct because "it has a performance cost", in my opinion. A lot of things have a performance cost. But the conclusion to optimize, or even avoid them, should come after you profile the speed of a concrete code, and indeed see that the bottle-neck lies within is / as operators.
Recent
