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

[Michael Van Canneyt]

On Mon, 15 Oct 2007, Daniël Mantione wrote:

> 
> 
> Op Mon, 15 Oct 2007, schreef L:
> 
> > Daniel Wrote:
> > >
> > > Basically, 2/3 of this unit is duplicated functionality. Interresting
> > > functions I cannot get somewhere else are string and path manipulation
> > > routines like extractfile*, trim*, wraptext.
> > >
> > 
> > Yes.. it duplicates functionality because it was a prototype or proof in
> > concept. I planned to wrap those functions like you say.  There are also
> > some functions in StrUtils which rely on sysutils that can be pulled out
> > quite likely.. I've pulled some out already in CompactStrUtils as a proof
> > in concept.
> > 
> > So the sysutils unit, can be arranged in a way that it wraps the ExtractFilePath
> > and friends. We will store those functions in a separate unit together, or an
> > include file. I need to know what you think is better.. an include file or a
> > unit that is put in uses clause. This unit that contains extractfilepath and
> > friends can be put in the uses clause of sysutils, and then can be put into
> > another unit called something like compactsysutils. That name is too long.. what
> > should we call the unit?
> 
> 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.

A small remark before you get too excited:

Sysutils has a fixed interface, for Delphi compatibility. Therefor it does
not tolerate changes to the interface. If you move the implementation to
another unit, the risk exists that someone "optimizes the interface" 
and thereby breaks Delphi compatibility. This should be avoided at all cost.

Michael.