Re^4: DBI: passing undef as an argument

You trying to prove it shouldn't be used by saying we should use two different types of it.

You trying to prove it shouldn't be used by saying it's handy.

You explain that it's flawed, but something being flawed shouldn't necessarily be avoided.

To say the least, you haven't made your point.

Comment on Re^4: DBI: passing undef as an argument

Replies are listed 'Best First'.
Re^5: DBI: passing undef as an argument by CountZero (Bishop) on Aug 12, 2009 at 19:51 UTC
The two different types of "NULL" solve the problems the one "NULL" causes. It may be handy in its implemention, but it is heresy in the model. As the implementation of the relational model (i.e. SQL) is already flawed in several respects if one looks at the requirements of the relational model, you cannot mend it simply by avoiding to use "NULL", but neither should one compound the problems by an indiscriminate use of "NULL". I wasn't trying to "make a point", I just hoped to explain that the use of "NULL" is not free from problems. CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James	[reply]

Replies are listed 'Best First'.

Re^5: DBI: passing undef as an argument
by CountZero (Bishop) on Aug 12, 2009 at 19:51 UTC

It may be handy in its implemention, but it is heresy in the model.

As the implementation of the relational model (i.e. SQL) is already flawed in several respects if one looks at the requirements of the relational model, you cannot mend it simply by avoiding to use "NULL", but neither should one compound the problems by an indiscriminate use of "NULL".

I wasn't trying to "make a point", I just hoped to explain that the use of "NULL" is not free from problems.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

[reply]