[fpc-pascal] Here is real time graphics and physics simulation library

[Michael Van Canneyt]

On Sun, 31 Jul 2022, Anthony Walter wrote:

> Michael, it's the same logic behind my now 12 year old Bare game system
> that did the exact same thing. I am creating a small lPascal ibrary that
> removes a lot of cruft and depends minimally on SDL for creating windows,
> managing input, handling sound, threads / mutexes. and move most of the
> core of what you need into a single unit (Tiny.System). In to browsable and
> organized uint replaced all string handling with much more efficient and
> powerful functions (see my FTP client and other socket protocols, my JSON
> parser, ), I also add in multicast delegates for events, path handling,
> file handling, file search, stream handling, and better threads (my simple
> threads were copied into ).

'better this or that' is a matter of opinion. I won't argue that.

Please stick to facts:
your code has demonstrably become inoperable with the rest of FPC. 
Since there are many things you do not provide but which are needed 
in real-world programs, that makes it de facto useless.

>
> One of the big problems IMO of the FPC base library, as compared to Delphi,
> which I have brought up here before, is that in 1995 - 2001 while people
> were using Delphi, they could learn by reading the source code to
> SystUtils, Classes, Controls. This is something I found to be invaluable,
> not only as a much better way of gaining an understanding of what is
> happening, but also a better way of debugging and painting.  As I have
> mentioned before, and have received the response that you're not supposed
> to read the source code with the FPC base library, you're supposed to just
> already know it.

Why we would forbid or discourage anyone to read the source code of 
an open source system is beyond me. That's why we write open source
software, so you can read it ?

That aside, I don't see how your system differs from the sysutils we ship, 
and hence how it solves the problems you mention, in particular you're also 
supposed to "just know it".

> I hope you or others here are not offended by either my by my library
> design or my rational included in this reposne.

I am not at all offended, rather the opposite:
I think it is a great pity that your code becomes inoperable with the 
rest of the Object Pascal ecosystem, hence my original question of "why?".

I would love to use your graphics library, but I won't because then I cannot
use the rest of FPC together with it, effectively making your system useless
to me, no matter how well the graphics layer works.

If you don't like the SysUtils API, I can understand it, since I myself
think it has become bloated over the years. Alas, for Delphi compatibility, 
we must follow suit. (although some things can be remedied, see below), that
you pose Tiny.System as an alternative for this: also fine, no problem.

But there is IMHO no valid reason not to base Tiny.System on top of sysutils
for exception handling, except the earlier mentioned 'not invented here'.

The only solution I can think of is to split out the exception handling of
sysutils into a lower-level unit with some glue to make up for the format
constructor and type aliases for backwards compatibility (an old idea of
mine). Then you could strip the exception code from Tiny.System and use 
this new unit and all would interoperate again.

But maybe then you'll probably bring up the 'unreable code' argument again ? :/

Michael.