Op Tue, 16 Oct 2007, schreef 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.
Yes, but there already exists a raise-less version of strtoint, called
val. So, there is IMO absolutely no need for an exceptionless version of
strtoint in another unit.
What does a raise call rely on? I can play and find out, but maybe you know
off
hand.
Afaik it is a statement, therefore handled by the compiler.
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.
Exactly, we should not put ifdefs into sysutils. This would useless
anyway, since then the decision is made at compile time, and users
generally don't compile sysutils themselves. I agree a forked unit can be
easier to maintain on itself, but on the other hand it causes a serious
problem for the maintenance of the project, since updates and bugfixes
will have to be applied in two places. Therefore moving the implementation
of some group of related functions, which you have an interrest in using,
without being forced to have the exceptions as well, is the only sane way
of handling this.
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?
There is no need for a raise call to work inside a fsutils. All that is
needed is that sysutils raises an exception on an error condition, and
this raise call can be in sysutils itself.
Compare again inttostr. The actual implementation, val, is in the
system unit. The only thing sysutils does is that calls val and raises
an exception on error.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel