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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
