Leyne, Sean wrote:

>Jim,
>
>
>
>>Frankly, I don't think there should be any difference between system
>>
>>
>and
>
>
>>user defined functions other than system functions show up
>>
>>
>automatically
>
>
>>on Firebird installation or update. A function is a function.
>>
>>
>
>I don't believe you said that!!!...
>
>While a function is a function, the implementation can be VASTLY
>different.
>
>Leaving aside the possibility of a different number of
>arguments/parameters and their datatypes, the logic/implementation can
>be completely different!
>
>
>

Sean, my friend, you completely missed my point. I was arguing that in
a sane world, the requirements drives the design, and the design drives
the implementation. The traditional Firebird way is to do the
implementation first, and let the implementation determine the requirements.

I'm not trying to tell anyone how to design or implement anything; I've
retired from those activities. I am suggesting that understanding the
requirements is an essential first step in software architecture. Put
the requirements first, in this case, forces you to consider issues like
who defines the name space, what names can be overridden, and whether a
user's investment in a working application is safe if a Firebird
developer wakes up one day with a hot new a idea for a system
function. Perhaps, just perhaps, producing a set of requirement might
prompt someone to think about the configuration management going forward
as opposed to the way it was done in the past.

The physical implementation of functions is next to irrelevant. A
function can be implemented in the engine one day, moved to an separate
library the next day, and re-implemented with an internal JVM a week
later. Which is better is a low level pragmatic decision that shouldn't
concern anyone outside the engine. How the functions are described is
of legitimate concern because a restrictive mechanism can unreasonably
limit the options available for implementation.

Kindly remember that I invented the idea of user defined functions in
the first place. From the day I decided to proceed with the idea I have
been uneasy with the idea of external code running inside the engine.
The security and reliability implications should cause any reason person
concern. Allowing a function library to run inside of a controlled
sandbox like a JVM is a great step forward. Many, particularly the
Yaffil crowd, will argue that performance dictates functions be hand
coded in assembler. Others will argue that any proper function must be
implemented as subclass of an STL template. Both are wrong -- the
architectural design must allow for specification of functions in
assembler, C++, Java, or even Delphi. Not all have to implemented, of
course, but to define a mechanism that precludes future development is
be a serious mistake.

The Firebird project has many, many institutional problems (the
brain-numbing idea of not putting documentation on line is probably the
worst, but there are others almost as bad). But ranking up there is the
refusal of Firebird engineers to recognize that requirements drive
semantics and semantics drive implementation. Engineers must understand
that deciding what should be done is more important than how it is done.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376