[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Directories named *.kdelnk : bug in kfm or KSimpleConfig ?
From:       Stephan Kulow <coolo () kde ! org>
Date:       1999-01-06 23:08:30
[Download RAW message or body]

Andreas Pour wrote:
> 
> "Patrick D. Dowler" wrote:
> 
> > On Wed, 06 Jan 1999, Robert Hagemann wrote:
> > >I think, we both share the point of view, that KSimpleConfig has to
> > >check the given file. But I disagree, that kfm ( or any other
> > >requester) should make use of this feature in 'unexceptional cases'
> > >It should not 'happen anyway'!
> > >
> > >If You use this feature of file checking, which is not the 'core
> > >competence' of KSimpleConfig, You get a system with high coupling
> > >which is less maintainable on the long run.
> > >
> > >Imagine, in a few months, someone decides to redesign KSimpleConfig.
> > >Ideally, this job is to look at the responsibilities of the Class
> > >( the services, that are provided by KSimpleConfig -- the core competence)
> > > and to handle all error conditions that are possible *in this new
> > >redesigned context*. In a high coupled system, where kfm uses the
> > >file analyzing cap's of KSimpleConfig, the old error handling is to
> > >be taken into consideration additionally! One more thing that is
> > >going to be forgotten a few months later.
> >
> > This is a good argument, and one I hadn't considered fully. Having kfm
> > use KSimpleConfig's error checking makes the error checking part of the
> > API for the class - future versions by the same name would have to keep
> > all of the old API or lose source compat, thus gaining an ever larger,
> > more complex, and less usable API  - a problem some well known
> > backwards-compatible software giant has :-)
> 
> While this changed-API issue is always worth considering, I think in this case
> it is not an issue.  We were talking here about whether or not a file can be
> opened for reading configuration information.  The problem was KSimpleConfig
> does not check to see if a file it is trying to open is a regular file (as
> opposed to a directory, symlink, named pipe, or what-not, or perhaps doesn't
> even exist).  I fail to see why checking to make sure you are opening a valid
> file would ever be removed from the API.
> 
> Plus, if there are 100 calls to KSimpleConfig, why should there be 100 extra
> lines of code (one before each KSimpleConfig call) to call a function that
> does the checking (not to mention that it is easy to forget to make the
> file-check)?  I think we can all agree that every file should be checked
> before it is opened, that is part of the process of opening a file, and
> IMHO this responsibility belongs in the library/object that handles the class
> and opens the file (e.g., there may be any number of requirements for a config
> file besides file type, such as format, and it is not the responsibilty of the
> client to check these things, but the library/object; that way if the class
> requirements for a config file change, every client call to KSimpleConfig does
> not have to be changed).
> 
I don't know if everyone joining this discussion knows about the code ;)

The "real" problem is that QTextStream::eof returns always false, even
if the
file it has been created with is a directory. So KSimpleConfig is not
really
to blame, since it already checks if QFile::exists returns true.

I would blame QTextStream if I had to say something, but since there is
a bug
KSimpleConfig has to work around it. That's what I say ;)

Greetings, Stephan

-- 
A big plus when your parents split up, is, that you don't
have to imagine them doing it again. * Mr. Rhodes

[prev in list] [next in list] [prev in thread] [next in thread]