Re: OO versus RDB

Marshall wrote:
> What my job is has no bearing on whether arguments about
> which definition of a term is right are interesting or not. Such
> arguments are always uninteresting. It is the semantics behind
> them that are interesting.

How can you discuss semantics if you can't agree on what you're discussing the semantics of ? Definitions are important; that's why we have so many bunfights in these newsgroups about them.

> I keep focusing on the semantics
> and you keep arguing about the defintions. So far you have
> not said anything of interest.

> Although you have amply
> demonstrated my earlier point, which is that people get
> unbalanced when you point out that return values are not
> affected by writing to global variabes.
>

I didn't see Adrian getting unbalanced; just disagreeing with you. And it's a very subtle discussion point we're getting at.

If we're discussing a "function" which always writes a predictable value based on the inputs to a global variable, this "function" could still be termed both pure (the output always depends solely on the input) and referentially transparent (that is, the function body could be written in line with the parameters substituted with no change of overall meaning, or another way, the same "net effect"). However, I would still deny that this subroutine is a function, because it is producing more than one output; you would have to consider the output to be both the return value *and* the updated store, especially if you're in a language like Pascal or C which exist to describe store changes. (As a side note, I would also remark that when I was learning Pascal it was considered exceptionally bad form to have a function alter anything in store; a function was there to compute the returned value. If you wanted to return more than one value, that was a procedure. This was, however, only a stylistic consideration, although I think a function that had the kind of side effect we're talking about here would be considered a nasty surprise by many.) And as Adrian said, if your "functions" create side-effects, you both inhibit the ability to safely optimise your code, you create possibly unexpected interactions with short circuit evaluation, you could find interesting issues with an overambitious optimiser, etc. etc. etc.

"Side effects" (as in changes to global variables) are bad news; they have been known and considered as such in imperative languages for many a long year. There are a few circumstances where they make sense in that environment, but they are still to be discouraged.

Also, you mentioned in an earlier post that your description of a function fitted with the mathematical definition of a function. Which mathematical definition of a function describes side effects ? Received on Mon Jul 10 2006 - 00:06:36 CEST