[Gambas-user] isNull()

[Bruce Bruen]

On Thu, 25 Nov 2010 10:01:42 am Benoît Minisini wrote:
> > I use IsNull extensively, is that going to be removed?
> > 
> > richard
> 
> No. I use it extensively too.
> 
> Here is the result of my thought:
> 
> - You can know the datatype of a variant with the TypeOf() function. You
> don't have to use the current IsXXXX() functions.
> 
> - But you often need to know if a string can be converted to a number, an
> integer, a float, a date.
> 
> - You normally want to know that for localized strings get from the outside
> (i.e. the user). For non-localized strings, they are intern to your
> program, so you should know what you are doing.
> 
> So:
> 
> 	IsNull(x) -> kept its behaviour.
> 	IsInteger(x) -> If Val(x) returns an integer
> 	IsFloat(x) -> If Val(x) returns a float
> 	IsDate(x) -> If Val(x) returns a date
> 
> They should be enough. But I could add:
> 
> 	IsLong(x) -> If Val(x) returns a Long
> 	IsSingle(x) -> If Single(x) returns a Single.
> 
> Regards,
Benoît,

I would like to see the generic IsNumber retained.  When dealing with external 
data sources, i.e. data from an external system source not "a user" the 
content of data fields in a database can vary widely over time. In different 
eras, a particular column may have it's type changed in the source database 
system but the existent data remains undisturbed.

Although it sounds weird, we often see data columns on mainframe and even on 
some PC based rdbms that have gone from a text (or char or varchar) to a 
numeric type, to a different numeric type and so forth.  In these database 
systems, any new inserts or updates will conform to the current type 
definition.  However, existing data is left as is.

So if "booktype" was originally char(1), then became charvar then became a 
specific structured datatype (for example, some of the custom types provided 
for in postgresql), we still see instances of, say "A" being returned by the 
dbms for booktype.  (The way we handle this is by way of our own postgresql 
"front end" database that accesses the remote dbms and returns text fields for 
any and all columns that contain suspect data types.)

In the main, I don't care if the field contains an integer or a float (or a 
long or single etc) just that it contains a number and not any non-numeric 
data.  I will worry about the representation after I have determined that it 
is a number.

I realise that this is a fairly arcane use of gambas, but the speed that we 
can develop (and run) filters based on this approach is why I chose gambas in 
the first place.  As I said, we use a 80-20 rule to get to the core issue of 
the data as soon as possible.  The parsing filters get more and more complex 
for each 20% left over.   So the ability to recognise "generic" datatypes in 
string values, "is it a number, good, then return true else start looking for 
other clues as to what it is supposed to represent ... does it look like it 
might be a date? If so then try to decipher the date structure, else does it 
look like a "known" construct (i.e IF wkstr LIKE "*(*%)*" then ...) etc etc.


Oh, and by the way, I too use IsNull extensively, specifically to provide 
"lazy loads" of subordinate persisted objects, usually collections, whose 
content is not required unless specifically accessed.  For example, a "Book" 
object may have a property which is an "Author" object.  When the persisted 
book object is loaded from the database, the author object is not loaded until 
the program actually accesses the book.author property, viz

PRIVATE FUNCTION MyAuthor() as Author
	if IsNull($myAuthor) 
		$myAuthor=NEW Author
		$myAuthor.LoadDB(ME.AuthorName)
	endif
	RETURN $myAuthor
END

(obviously simplified to exclude error checking).

-- 
best regards
Bruce Bruen