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

#26 K*_SYSTEM_CLOCK should not be inside kernel

trunk
open
Eric Bezault
kernel (4)
5
2009-02-08
2009-01-28
Jocelyn FIAT
No

Why KI_SYSTEM_CLOCK and KL_SYSTEM_CLOCK are inside library/kernel/misc
when they would be better in library/time/clock
?

During convertion to void-safety, we made one .ecf per library, this allow us to work on subset of Gobo, and to see the various dependencies between components.
And since K*_SYSTEM_CLOCK are in the kernel, and relies on C_DATE, this forces gobo_kernel.ecf to use EiffelTime.

Apart from the fact it "includes" more classes than needed for the kernel, this adds an uneeded dependencies on Date.
Any comment on that?

Discussion

  • Eric Bezault
    Eric Bezault
    2009-02-08

    There is an historical reason why KL_SYSTEM_CLOCK is in $GOBO/library/kernel. This library was initially about providing an adaptation layer between the various Eiffel compilers supported by Gobo. This is where the infamous .ge files were (and some are still) hosted. The class to use officially is DT_SYSTEM_CLOCK. But its implementation relied on various compiler dependent functionalities from either SmartEiffel, ISE Eiffel, Visual Eiffel. Hence the introduction of this ancestor class KL_SYSTEM_CLOCK in a .ge file in $GOBO/library/kernel. Now that Gobo supports far less Eiffel compilers, the .ge file is not needed anymore, and in fact KL_SYSTEM_CLOCK and DT_SYSTEM_CLOCK could be merged back into a single class DT_SYSTEM_CLOCK. But who knows if this class KL_SYSTEM_CLOCK will have to be reintroduced again if Gobo supports more Eiffel compilers in the future. And of course, when getting rid of a class like here with KL_SYSTEM_CLOCK, there is always the risk that someone was using it.

    Note that the dependency to ISE's EiffelTime has been there for ages. Do you think that this is a real problem?

     
  • Eric Bezault
    Eric Bezault
    2009-02-08

    • assigned_to: nobody --> ericb
     
  • Jocelyn FIAT
    Jocelyn FIAT
    2009-02-27

    My comment was just in relation to the notion of "library".
    It looks just weird to see the kernel depending on time.

    However, I understand you argument.
    Maybe the "kernel" can not be seen as a library.
    Or maybe a library depending on "time library".

    During void-safe conversion of Gobo, we tried to have gobo_kernel.ecf, gobo_structure.ecf .. and so on. To avoid loading all gobo, each time we want to use it (for now, using gobo.ecf).
    And when I think in term of library, I always try to minimize dependences between libraries.

    That was my whole point.
    But no, this is not a critical problem, neither a real problem.

     
  • Eric Bezault
    Eric Bezault
    2009-03-02

    Well, perhaps it should not have been called 'kernel'. As I already said, it is more an adaptation layer on top of different Eiffel compiler classes. I think that it is nevertheless a library. And it's called 'kernel' because all other Gobo libraries rely on it. And I don't remember, but I would not be surprised that some of the Eiffel compilers that were supported in the past by Gobo provided the time facilities in their "kernel" library.

    OK, ISE does not provide time facilities in its kernel library. But what does kernel library mean anyway? Why aren't you questioning the fact that file facilities are included in ISE's kernel library instead of being provided in their own library like it is the case for time facilities with EiffelTime? And is it normal that we cannot use ISE's kernel classes without pulling all container classes from EiffelBase?

    Gobo's adaptation layer library pulls ISE's EiffelTime. I don't think that it is a big deal compared to the size of EiffelBase that you have to include when you just want to use basic kernel classes. It is true that there is no need for KL_SYSTEM_CLOCK in Gobo's adaptation layer library anymore. So there is an opportunity to remove it in the future and hence remove the dependency to EiffelTime. But that should be done properly with an obsolete phase. It would also be nice to have a possibility in ECF to be able to have conditionals which indicate which compiler is used. Indeed, when using ISE's compiler EiffelTime should be included, but not when using gec.