[fpc-devel] Re: fpc-devel Digest, Vol 40, Issue 16

[L]

> Let's first discuss a plan, then we'll see about the name. Suppose we put =
>
> everything that does something with paths and files in a unit:
>
> * Extractfilepath and friends
> * Exec, findfirst, etc.
>
> ... then it could be called something like fsutils, "fs" from filesystem.
>
> So, let's first discuss the purpose of the unit and which functions =
>
> types will be in it.
>
> Dani=EBl
>

One thing that has come to my mind now is the exceptional raise calls in some of
the functions.  Some of the functions don't contain raise calls, which is great
because they are automatically standalone capable as is. Functions without any
raise calls AFAIR are ExtractFilePath and friends. Sysutils

Functions like strtoint however have raise calls.

What does a raise call rely on? I can play and find out, but maybe you know off
hand.

The raise call can be ifdefed.. which gets messy, which is why I probably forked
the unit.. because sometimes a forked duplicate function is easier to maintain
than a single ifdefed function. Now it is all coming back to me. However, it
isn't all bad news.. as I said many functions do not rely on raise and can be
moved to fsutils immediately without any hassle.

If a raise call can work in fsutils.pp somehow, that's the other option. I am
not familiar with how raise calls work when you don't have a sysutils in the
uses.. wasn't it one of the features added to fpc recently: the ability to use
exceptions without sysutils some way? But would this require syntax changes
anyhow, as a different style of raise is used when you don't have sysutils in
uses?

One other quick thought... many of the algorithms are robust in sysutils and
don't change. So duplicate code isn't the end of the world for short functions
like StrToInt. i.e. one that uses sysutils exceptions and one that uses.. the
other special non-sysutils exceptions recently implemented in fpc, or no
exceptions.