Hello Helen,

Friday, June 13, 2003, 8:02:11 AM, you wrote:

HB> At 07:46 AM 13/06/2003 -0300, you wrote:

>>Hello Doug,
>>
>>Thursday, June 12, 2003, 10:36:23 PM, you wrote:
>>
>>DC> At 6/12/2003 08:08 PM (Thursday), Daniel Rail wrote:
>> >>- Complete evaluation is sometimes convenient when one operand is a
>> >> function with side effects that alter the execution of the program
>>
>>DC> This is poorly stated. By definition "side effects" do not alter the
>>result
>>DC> of the expression evaluation (what I think you refer to as "the execution
>>DC> of the program") but they can nevertheless be important. If I wrote a UDF
>>DC> which logs execution somewhere I think would want it called wherever I
>>used it.
>>
>>It's not my thinking and wording. It's the definition that I found in
>>Delphi's help, word for word. And, reading the statement properly, it
>>does refer to a function, and in Firebird's case it would be a UDF, as
>>in your statement. I haven't thought of that scenario.

HB> So, Daniel, you are saying that calling a UDF as part of an evaluation
HB> sequence could change the state of the database and therefore alter the
HB> result of the OR test? I don't see it. Please give an example of how this
HB> could happen.

No, that's not what I meant. What Doug was saying is that if, in the
UDF, there is a logging feature(as an example), by simply writing to a
text file, whenever the UDF is called. And, that the developer is
expecting that UDF to be executed wherever it is used, this is the
side effect that can happen. The end result of the evaluation doesn't
change, but if the evaluation gets short-circuited before the UDF is
supposed to be called, then the UDF is not called and it is not the
expected result(i.e.: performing the logging operation) that the
developer had in mind.

I think the only side effects possible would be to perform an external
operation to Firebird(i.e. writing to a text file).

--
Best regards,
Daniel Rail