Hi,
On Mon, May 25, 2015 at 7:59 AM, Alexey Zakhlestin <indey...@gmail.com>
wrote:
>
>
> I'm not sure how JSON Schema would help here. The issue is about
> converting from json's huge numbers to limited PHP's numbers. Schema just
> doesn't have notion of native types
>
>
The idea would be to use JSON schema to specify structure of the JSON and
select just the specific parts that can be converted to string. Let's
imagine that you have object with this structure:
{
"a": 1.23234,
"b": 11111222222222222.111111111
}
Now you really don't want to loose precision for b but you would like to
use float for a. You can create a simple json schema:
{
"title": "Simple Object Schema",
"type": "object",
"properties": {
"a": {
"type": "number"
},
"b": {
"type": "string"
}
}
}
The great thing on JSON Schema is that it is not limited on the specified
fields (the schema of json core schema does not disable
additionalProperties which means that any additional properties are
allowed). That means that we could add our parameter to specify a class of
the object. For example if we create classes that you proposed in the
previous thread, we could do following:
{
"title": "Simple Object Schema",
"type": "object",
"properties": {
"a": {
"type": "number"
},
"b": {
"type": "object",
"class": "Json\Float"
}
}
}
It would probably require some allowing only classes that implements some
interface which allows JSON serialization (encoding) as well as
unserialization (decoding). That could be also used for user classes. We
would also need some flags to select type of the validation (strict
validation, validation with conversion if possible...).
There is much more that could be done including overloading validation
errors... JsonSchema adds of course more features that are however
off-topic...
Anyway, as I told in a previous thread, while approach of this rfc solves
> immediate problem, it is not future-proof flexible and exposing low-level
> type based parsing is a better idea
IIRC your initial proposal was about converting everything to objects which
is not flexible at all as it suffers exactly from the same problems as this
RFC. The only difference is using object instead of string. I think that
the above is much more flexible...
However as I said before it is quite a big feature that could be done only
in the minor version and requires considerably more time for implementation.
Cheers
Jakub
