On Wed, Feb 22, 2017 at 3:45 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:
and try to make a field containg null typeof in javascript - its an empty
object!
The whole point of JSON is actually so that JavaScript data can be
easily transported. ("JSON" means "JavaScript Object Notation".) It
would be crazy if JSON were specified in such a way that you can't
work with it in JavaScript.
I'm not sure what you're trying to say, honestly. The nature of
JavaScript is such that variables do not have static types. In dynamic
languages like JavaScript, "data type" is a property belonging to a
*value*, not to a variable. Any variable can take on values of any
type. In JS, null is a value, and its type is "object".
If you have some code which is expecting a string, but you know that
you might receive a null instead, then you just include logic to test
for null.
IBM is wrong, you cant have a string that is null its a special entity
And in javascript you can't have a string or a number that contains null
that is a empty object
When IBM (or anyone else) talks about a "string" that contains a JSON
null, they are talking about mapping (for import or export). A numeric
database field that contains NULL would map to the same JSON null.
Yes, within JSON (and JavaScript), you can't tell whether a null came
from a string field or a numeric field. But so what? If you are
importing JSON data into a database, then the database field will
impose a type, and a JSON null will be equally happy in a string
database field or a numeric database field. I really don't see the
problem.
DB null capable fields is something the devil has created to make life
miserable for programmers!
I will only go so far as to say NULLs are annoying to have if you
don't personally need them. I will also agree with anyone who says
that *RPG* has especially poor native null handling. But in situations
where NULL is handy, the alternative workarounds are just as annoying
(or worse) as not being able to have NULL.
John Y.
midrange.com
