Support 'function' data type

[bitmage]

Now I know what you're gonna say. Functions aren't valid json. Bear with me.

JSON schemas are really useful, and shouldn't be limited to just strict JSON cases. If you add in the capability to detect functions, you've now got support for all javascript types and therefore have broadened the usefulness.

This doesn't interfere with any of the existing capabilities, as you can see. The tests all still pass, and I've added a few more. There a couple possible cases to consider:

1. The user of the library doesn't have functions in their target JSON, or their schema. Great, everything will work as according to spec.
2. The user of the library has functions in their target JSON, but not in the schema. Type checks still work as normal, so if you're expecting an object and you get a function, the schema validation will fail. This is actually an increase in accuracy, since with the previous implementation this 'function' would have been detected as an 'object' and the test would pass.
3. The user has functions in their schema, but not in the JSON. This should be the same as the previous case. Type checking still works as normal.

What do you say? Can we have our cake and eat it too?

[toverly]

Maybe pitch your idea to the json schema people?

[bitmage]

Well, I imagine they would reject it, and rightly so. It doesn't have anything to do with JSON in the universal sense. For instance it wouldn't make any sense for a .NET or Python implementation to support JavaScript functions. However, it seems handy in the case of a JavaScript implementation. It allows you to do extra things with no perceivable disadvantage.

Can you think of any cases where this would be a hindrance, or lead to problems down the road?

On Mar 16, 2013, at 12:41 PM, toverly [email protected] wrote:

Maybe pitch your idea to the json schema people?

— Reply to this email directly or view it on GitHub.

[pvorb]

I would say this feature doesn't really belong to JaySchema. It does JSON Schema validation according to the spec and that's all. Keep it simple.

You might want to consider to plug this functionality into JaySchema. But therefore one would need some kind ofplug-in interface.

[bitmage]

If you wanted to support this sort of functionality as plugins, you would essentially be building an extensible type system. The way I would suggest going about this is by letting the consumer of the library inject their own 'apparentType' function.

However, I'm still not seeing why this wouldn't be supported natively. If you really want to be true to the JSON spec, JaySchema should throw an exception or fail to parse a document with functions. Those aren't valid JSON. But I think it's wise to strike a balance between being academically correct and building a tool that's useful to people.

Either way, I have what I need. I'm just trying to make this work accessible to other people so they don't have to re-implement it.

[redben]

+1 though not part of JSON, this would be useful for example to enforce "javascript interfaces", or to document these.