Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#17 Rearchitect the LXR::Files class to LXR::File

open
nobody
General (16)
5
2007-03-30
2007-03-30
Paul D. Smith
No

The current LXR::Files class has a single global object that represents a backend (plain, CVS, etc.) Methods of this object take a filename/release pair and return various information about that file using that backend.

I don't think this is the proper organization and this should be rearchitected. I propose the following:

1) The current LXR::Files class should be reworked to be a very small class, that just does whatever setup is needed for that backend type. It could be renamed to something like LXR::FileType or something, maybe. It's possible we won't even need this: we'll have to see.

2) A new LXR::File class should be created. An object of this class will represent ONE file/release. It will have various methods to retrieve the path, content, size, etc.; these don't need to take any arguments (generally).

LXR::File is probably going to be a superclass with subclasses for each backend, and the actual objects returned would be objects of the subclass. The LXR::File class would provide basic method implementations (probably similar to today's LXR::Files::Plain class) which various other backends could override.

Once this is done I think a lot of other things, like the web caching described in another feature request, become more straightforward to implement.

Discussion

  • Paul D. Smith
    Paul D. Smith
    2007-03-30

    • labels: --> General
     
  • Malcolm Box
    Malcolm Box
    2007-04-13

    Logged In: YES
    user_id=215386
    Originator: NO

    Excellent idea, this would make a bunch of things easier and be higher performance with certain SCM systems.