Subject | Architectural Cleanliness: CVT_move |
---|---|
Author | Jim Starkey |
Post date | 2003-12-20T16:40:42Z |
There is an exported symbol in the gds32 library, CVT_move, that does
not belong there and is causing me great pain. The function is a
database internal function used to move or convert data represented by a
descriptor into a type represented by a second descriptor. It is a very
useful function in the engine, and should never have been exported.
Among the many, many problems of exposing an internal engine function are:
1. It doesn't follow naming conventions
2. It doesn't follow error reporting conventions
3. It uses internal engine data description functions which are
subject to change without notice.
4. It uses C linkage while the internal function should legitimately
be a C++ function.
5. It breaks the layering. An application program may be calling an
interface that doesn't have access to engine code.
6. It has put the Wolf into a great deal of inconvenience, not the
least is the need to write this message. The Wolf is not happy.
If people want to contribute as developers they need to accept some
professional discipline, including a respect for architecture. Just
because someone has programmed himself into a corner is no reason to
break the layering a large software system.
Crudities like this has made it very difficult to pry apart the layers
of Firebird, impeding future development.
I know exactly why the function was exported. Somebody wanted a general
purpose conversion. Reasonable. But cloning a copy of cvt for gpre or
a general purpose utility library (which would have been a very good
thing), it would have involved untangling cvt from other engine modules
with which it was rightly enmeshed. Seemed a lot easier to just export
an internal symbol and run with it.
Wrong. Bad developer! Bad developer! Go to your crate!
What I'm supposed to be doing is re-establishing the Interbase
architecture to enable multi-threaded embedded use on 64 bit
multiprocessors. What I'm doing, however, is cleaning up architectural
dog poop from a lazy bastard.
If you guys are serious about making Firebird a DBMS of the first rank
you are going to have to learn respect for architecture.
Grrrrr.
--
The Wolf d/b/a The Grinch
[Non-text portions of this message have been removed]
not belong there and is causing me great pain. The function is a
database internal function used to move or convert data represented by a
descriptor into a type represented by a second descriptor. It is a very
useful function in the engine, and should never have been exported.
Among the many, many problems of exposing an internal engine function are:
1. It doesn't follow naming conventions
2. It doesn't follow error reporting conventions
3. It uses internal engine data description functions which are
subject to change without notice.
4. It uses C linkage while the internal function should legitimately
be a C++ function.
5. It breaks the layering. An application program may be calling an
interface that doesn't have access to engine code.
6. It has put the Wolf into a great deal of inconvenience, not the
least is the need to write this message. The Wolf is not happy.
If people want to contribute as developers they need to accept some
professional discipline, including a respect for architecture. Just
because someone has programmed himself into a corner is no reason to
break the layering a large software system.
Crudities like this has made it very difficult to pry apart the layers
of Firebird, impeding future development.
I know exactly why the function was exported. Somebody wanted a general
purpose conversion. Reasonable. But cloning a copy of cvt for gpre or
a general purpose utility library (which would have been a very good
thing), it would have involved untangling cvt from other engine modules
with which it was rightly enmeshed. Seemed a lot easier to just export
an internal symbol and run with it.
Wrong. Bad developer! Bad developer! Go to your crate!
What I'm supposed to be doing is re-establishing the Interbase
architecture to enable multi-threaded embedded use on 64 bit
multiprocessors. What I'm doing, however, is cleaning up architectural
dog poop from a lazy bastard.
If you guys are serious about making Firebird a DBMS of the first rank
you are going to have to learn respect for architecture.
Grrrrr.
--
The Wolf d/b/a The Grinch
[Non-text portions of this message have been removed]