That was kind of my point. JSONItem cannot limit itself to the data types it understands, because any object may have an operator_convert to string and it wouldn’t know. Date doesn’t happen to have one.
Actually when a Date is assigned to a Variant it does auto convert to string:
dim v as variant = new date
dim s as string = vyou get something like: 2016-03-11 08:12:36
And this is true for many objects assigned to a Variant, including custom objects with an Operator_Convert to a string.
But that is not related. Variant has besides other a StringValue method and the Xojo compiler can coerce the data type from the left-hand-side of the statement.
As JSON does not define how a date should be stored, it is up to you as the developer to do it.
[quote=252576:@Massimo Valle]Actually when a Date is assigned to a Variant it does auto convert to string:
dim v as variant = new date
dim s as string = vyou get something like: 2016-03-11 08:12:36[/quote]
Variants and Dates have a special, hardcoded, relationship for historical reasons.
Again, the point is, JSONItem should only accept the JSON valid types and raise an exception immediately if something not valid is appended.
This is a bug IMHO.
However since it accepts everything (variant), anything can be converted to a string should be work then.
And this is a feature request, again IMHO.
The problem here is that you misunderstand what a cast does - nothing more
A CAST is NOT a conversion operation which is why your cast doesn’t work - it doesn’t invoke operator_convert
Its literally “reinterpret this type as though is this type I’m casting to”
CType is an explicit conversion from the source to the destination type
Assignment to a different type invokes an implicit conversion
Both would use your operator_convert
In order to invoke your operator convert you have to convert it - which is why your cast didn’t work
Norman, while this thread originated from a wrong interpretation of a cast, the point is not that anymore.
And part of my misunderstanding comes from the odd behavior of this class.
This is what you misunderstand.
Dont think I misunderstand at all
[quote=252400:@Massimo Valle]Then it should probably check the appended items are valid.
From the LR: “Values can be any of the following types: Strings, numbers, JSONItems, arrays, Booleans, or Nil.”
[/quote]
[quote=252678:@Massimo Valle]Again, the point is, JSONItem should only accept the JSON valid types and raise an exception immediately if something not valid is appended.
[/quote]
SO HOW would it know its “not valid” ?
The JSON code can not tell IF the object passed can convert to a valid JSON type without trying to convert it to at least one of those.
And to know if it can be validly converted to any one of them then the json code would have to try ALL of them and see if any worked.
I doubt anyone would like that hit that would impose
[quote=252744:@Norman Palardy]Dont think I misunderstand at all
SO HOW would it know its “not valid” ?
[/quote]
Very easy: only accept valid types instead of a Variant.
@Eli Ott suggested a very simple workaround above, to get rid of the Variant.
The question is why it’s coded to accept a Variant?
I understand it’s useful to store different types in an array, but it should not be exposed.
but a type that CAN convert itself to a string is valid
or a type that can convert itself to a jsonitem is valid
its coded that way because storing something that can convert itself to a valid json type makes sense
and changing that API could break untold amount of code
we try really hard not to break code
[quote=252781:@Norman Palardy]but a type that CAN convert itself to a string is valid
or a type that can convert itself to a jsonitem is valid
its coded that way because storing something that can convert itself to a valid json type makes sense
[/quote]
That would be nice, but again my complaint is exactly because this is not what happens.
As already said I tried appending to a JSONItem an object for which both Operator_Convert As String and Operator_Convert As JSONItem exists.
But the object was added instead of its String or JSONItem conversion.
You also confirmed me this.
nm
the api is what it is
we cant change it as we might break a lot of code
so use it carefully
You can’t break something is already broken.
A JSONItem with an array of whatever object causing an exception when it’s rendered is useless already.
Please don’t forget the whole meaning of this class is producing valid JSON strings.
Stop ranting and calm down. JSONItem is not broken.
<https://xojo.com/issue/42959>
So Norman can close it and say it’s broken by design or that it’s not a bug, is a feature request.
I’ll repeat
We have no idea how much code might already exist that depends on how things do currently behave
Changing that could break a lot of code and we do try to avoid that
Only when it is absolutely impossible to avoid do we do it - but we try REALLY REALLY hard not to
I have updated the summary to be more reflective of the issue you feel exists and made the case a feature request
Its possible we could do it without breaking code as if things can convert to one of the acceptable types then its possible we can switch the api so the conversion happens when added instead of when the jsonitem converts to a string.
We’d have to investigate the ramifications of doing that
Q.E.D.
BUG = Its NOT operating as designed. This is
That you disagree with the design & want is changed makes it a feature request
I’ll be ignoring the rest of this thread
Just for the records, here it’s a class to fix the exposed problems and enhance the JSONItem
https://forum.xojo.com/30912-jsonobject-class