Re: Possible sling JSONObject bug
IMHO equals should fullfill the spec - so equals should return true (and hashcode) should return the same value. Ordering of values is a propietary feature which can be used for explicit functionality like a userdefined displayorder. Adding restrictions by undefined (but common) behaviour might not be the best idea. Best regards, Dominik On Sun, Jun 7, 2009 at 8:40 PM, Felix Meschberger wrote: > Hi, > > Alexander Klimetschek schrieb: > > On Sat, Jun 6, 2009 at 5:55 PM, Felix Meschberger > wrote: > >>> On Fri, Jun 05, 2009 at 09:18:05PM +0200, Alexander Klimetschek wrote: > I think they are not equivalent in the strict Javascript sense, as the > order of the properties in an object is defined (you can iterate over > it). It is not to be seen as a pure hash map. > >> This is wrong. The spec explicitly states that there is no defined order > >> amongst the properties of an object. > >> > >> Now, in reality, the known browsers implement objects in a way, that the > >> properties have a factual insertion order. But, this is an > >> implementation specific thing. > > > > Ok, I didn't know it was specified as free. But since the popular > > implementations (browsers) all follow the same way, ie. keep the order > > (in Javascript), one should follow this to keep free from unwanted > > problems. > > I do not agree. One should follow the spec and consider the browser > implementations what they are: implementations of the spec where it > happens to be that the properties seem to have an order. > > But yes, the Sling JSONObject also supports the property ordering due to > popular request of users depending on this implementation specific... > > Regards > Felix >
Re: Possible sling JSONObject bug
Hi, Alexander Klimetschek schrieb: > On Sat, Jun 6, 2009 at 5:55 PM, Felix Meschberger wrote: >>> On Fri, Jun 05, 2009 at 09:18:05PM +0200, Alexander Klimetschek wrote: I think they are not equivalent in the strict Javascript sense, as the order of the properties in an object is defined (you can iterate over it). It is not to be seen as a pure hash map. >> This is wrong. The spec explicitly states that there is no defined order >> amongst the properties of an object. >> >> Now, in reality, the known browsers implement objects in a way, that the >> properties have a factual insertion order. But, this is an >> implementation specific thing. > > Ok, I didn't know it was specified as free. But since the popular > implementations (browsers) all follow the same way, ie. keep the order > (in Javascript), one should follow this to keep free from unwanted > problems. I do not agree. One should follow the spec and consider the browser implementations what they are: implementations of the spec where it happens to be that the properties seem to have an order. But yes, the Sling JSONObject also supports the property ordering due to popular request of users depending on this implementation specific... Regards Felix
Re: Possible sling JSONObject bug
On Sat, Jun 6, 2009 at 5:55 PM, Felix Meschberger wrote: >> On Fri, Jun 05, 2009 at 09:18:05PM +0200, Alexander Klimetschek wrote: >>> I think they are not equivalent in the strict Javascript sense, as the >>> order of the properties in an object is defined (you can iterate over >>> it). It is not to be seen as a pure hash map. > > This is wrong. The spec explicitly states that there is no defined order > amongst the properties of an object. > > Now, in reality, the known browsers implement objects in a way, that the > properties have a factual insertion order. But, this is an > implementation specific thing. Ok, I didn't know it was specified as free. But since the popular implementations (browsers) all follow the same way, ie. keep the order (in Javascript), one should follow this to keep free from unwanted problems. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: Possible sling JSONObject bug
Hi,
D. Stuart Freeman schrieb:
> OK, in that case it sounds like comparing the results of toString()
> should suffice for my purposes.
No, this won't work - technically - since the order of properties in an
object is *explicitly* defined as not being defined in the spec. In our
implementation we cheated a bit and make the order defined as "insertion
order" using a LinkedHashMap.
If you really would want to compare JSONObjects, we would have to
implement the equals method - probably in terms of the equals() method
of the underlying Map used internally.
Comparing toString is unreliable.
>
> On Fri, Jun 05, 2009 at 09:18:05PM +0200, Alexander Klimetschek wrote:
>> I think they are not equivalent in the strict Javascript sense, as the
>> order of the properties in an object is defined (you can iterate over
>> it). It is not to be seen as a pure hash map.
This is wrong. The spec explicitly states that there is no defined order
amongst the properties of an object.
Now, in reality, the known browsers implement objects in a way, that the
properties have a factual insertion order. But, this is an
implementation specific thing.
Regards
Felix
>>
>> Regards,
>> Alex
>>
>> --
>> Alexander Klimetschek @iPhone
>>
>>
>> Am 05.06.2009 um 21:00 schrieb "D. Stuart Freeman"
>> :
>>
>>> In the example I do both a toString() comparison and an Object
>>> comparison
>>> to show that it doesn't work. The problem is that in the current
>>> setup
>>> is as follows:
>>>
>>> JSONObject j = new JSONObject("{a:a, b:b}");
>>> JSONObject j = new JSONObject("{b:b, a:a}");
>>>
>>> There's no easy way to find out these are functionally equivalent.
>>> The
>>> toString() methods of those objects will return them with the
>>> properties
>>> in that order and as such will not be equal. Calling .equals on the
>>> JSONObjects won't work either because it calls Object.equals which is
>>> false.
>>>
>>> On Fri, Jun 05, 2009 at 12:16:13PM -0500, John Crawford wrote:
Well in you're example you used toString() before comparing.
Sent from my iPhone
On Jun 5, 2009, at 12:14 PM, "D. Stuart Freeman"
wrote:
> I just realized this is because JSONObject doesn't override equals.
> Maybe it should?
>
> On Fri, Jun 05, 2009 at 01:10:30PM -0400, D. Stuart Freeman wrote:
>> Should it hold that if we have two JSONObjects, j and k, that if
>> j.toString().equals(k.toString()) then j.equals(k)? I ask because
>> I've
>> found that it's possible to create JSONObjects where that isn't the
>> case.
>> Here's a quick, minimal example I worked up:
>> http://pastebin.com/f12de25b9
>>
>> --
>> D. Stuart Freeman
>> Georgia Institute of Technology
>
>
> --
> D. Stuart Freeman
> Georgia Institute of Technology
>>> --
>>> D. Stuart Freeman
>>> Georgia Institute of Technology
>
Re: Possible sling JSONObject bug
OK, in that case it sounds like comparing the results of toString()
should suffice for my purposes.
On Fri, Jun 05, 2009 at 09:18:05PM +0200, Alexander Klimetschek wrote:
> I think they are not equivalent in the strict Javascript sense, as the
> order of the properties in an object is defined (you can iterate over
> it). It is not to be seen as a pure hash map.
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek @iPhone
>
>
> Am 05.06.2009 um 21:00 schrieb "D. Stuart Freeman"
> :
>
>> In the example I do both a toString() comparison and an Object
>> comparison
>> to show that it doesn't work. The problem is that in the current
>> setup
>> is as follows:
>>
>> JSONObject j = new JSONObject("{a:a, b:b}");
>> JSONObject j = new JSONObject("{b:b, a:a}");
>>
>> There's no easy way to find out these are functionally equivalent.
>> The
>> toString() methods of those objects will return them with the
>> properties
>> in that order and as such will not be equal. Calling .equals on the
>> JSONObjects won't work either because it calls Object.equals which is
>> false.
>>
>> On Fri, Jun 05, 2009 at 12:16:13PM -0500, John Crawford wrote:
>>> Well in you're example you used toString() before comparing.
>>>
>>> Sent from my iPhone
>>>
>>> On Jun 5, 2009, at 12:14 PM, "D. Stuart Freeman"
>>> wrote:
>>>
I just realized this is because JSONObject doesn't override equals.
Maybe it should?
On Fri, Jun 05, 2009 at 01:10:30PM -0400, D. Stuart Freeman wrote:
> Should it hold that if we have two JSONObjects, j and k, that if
> j.toString().equals(k.toString()) then j.equals(k)? I ask because
> I've
> found that it's possible to create JSONObjects where that isn't the
> case.
> Here's a quick, minimal example I worked up:
> http://pastebin.com/f12de25b9
>
> --
> D. Stuart Freeman
> Georgia Institute of Technology
--
D. Stuart Freeman
Georgia Institute of Technology
>>
>> --
>> D. Stuart Freeman
>> Georgia Institute of Technology
--
D. Stuart Freeman
Georgia Institute of Technology
signature.asc
Description: Digital signature
Re: Possible sling JSONObject bug
I think they are not equivalent in the strict Javascript sense, as the
order of the properties in an object is defined (you can iterate over
it). It is not to be seen as a pure hash map.
Regards,
Alex
--
Alexander Klimetschek @iPhone
Am 05.06.2009 um 21:00 schrieb "D. Stuart Freeman" >:
In the example I do both a toString() comparison and an Object
comparison
to show that it doesn't work. The problem is that in the current
setup
is as follows:
JSONObject j = new JSONObject("{a:a, b:b}");
JSONObject j = new JSONObject("{b:b, a:a}");
There's no easy way to find out these are functionally equivalent.
The
toString() methods of those objects will return them with the
properties
in that order and as such will not be equal. Calling .equals on the
JSONObjects won't work either because it calls Object.equals which is
false.
On Fri, Jun 05, 2009 at 12:16:13PM -0500, John Crawford wrote:
Well in you're example you used toString() before comparing.
Sent from my iPhone
On Jun 5, 2009, at 12:14 PM, "D. Stuart Freeman"
wrote:
I just realized this is because JSONObject doesn't override equals.
Maybe it should?
On Fri, Jun 05, 2009 at 01:10:30PM -0400, D. Stuart Freeman wrote:
Should it hold that if we have two JSONObjects, j and k, that if
j.toString().equals(k.toString()) then j.equals(k)? I ask because
I've
found that it's possible to create JSONObjects where that isn't the
case.
Here's a quick, minimal example I worked up:
http://pastebin.com/f12de25b9
--
D. Stuart Freeman
Georgia Institute of Technology
--
D. Stuart Freeman
Georgia Institute of Technology
--
D. Stuart Freeman
Georgia Institute of Technology
Re: Possible sling JSONObject bug
In the example I do both a toString() comparison and an Object comparison
to show that it doesn't work. The problem is that in the current setup
is as follows:
JSONObject j = new JSONObject("{a:a, b:b}");
JSONObject j = new JSONObject("{b:b, a:a}");
There's no easy way to find out these are functionally equivalent. The
toString() methods of those objects will return them with the properties
in that order and as such will not be equal. Calling .equals on the
JSONObjects won't work either because it calls Object.equals which is
false.
On Fri, Jun 05, 2009 at 12:16:13PM -0500, John Crawford wrote:
> Well in you're example you used toString() before comparing.
>
> Sent from my iPhone
>
> On Jun 5, 2009, at 12:14 PM, "D. Stuart Freeman"
> wrote:
>
>> I just realized this is because JSONObject doesn't override equals.
>> Maybe it should?
>>
>> On Fri, Jun 05, 2009 at 01:10:30PM -0400, D. Stuart Freeman wrote:
>>> Should it hold that if we have two JSONObjects, j and k, that if
>>> j.toString().equals(k.toString()) then j.equals(k)? I ask because
>>> I've
>>> found that it's possible to create JSONObjects where that isn't the
>>> case.
>>> Here's a quick, minimal example I worked up:
>>> http://pastebin.com/f12de25b9
>>>
>>> --
>>> D. Stuart Freeman
>>> Georgia Institute of Technology
>>
>>
>>
>> --
>> D. Stuart Freeman
>> Georgia Institute of Technology
--
D. Stuart Freeman
Georgia Institute of Technology
signature.asc
Description: Digital signature
Re: Possible sling JSONObject bug
Well in you're example you used toString() before comparing. Sent from my iPhone On Jun 5, 2009, at 12:14 PM, "D. Stuart Freeman" > wrote: I just realized this is because JSONObject doesn't override equals. Maybe it should? On Fri, Jun 05, 2009 at 01:10:30PM -0400, D. Stuart Freeman wrote: Should it hold that if we have two JSONObjects, j and k, that if j.toString().equals(k.toString()) then j.equals(k)? I ask because I've found that it's possible to create JSONObjects where that isn't the case. Here's a quick, minimal example I worked up: http://pastebin.com/f12de25b9 -- D. Stuart Freeman Georgia Institute of Technology -- D. Stuart Freeman Georgia Institute of Technology
Re: Possible sling JSONObject bug
I just realized this is because JSONObject doesn't override equals. Maybe it should? On Fri, Jun 05, 2009 at 01:10:30PM -0400, D. Stuart Freeman wrote: > Should it hold that if we have two JSONObjects, j and k, that if > j.toString().equals(k.toString()) then j.equals(k)? I ask because I've > found that it's possible to create JSONObjects where that isn't the case. > Here's a quick, minimal example I worked up: > http://pastebin.com/f12de25b9 > > -- > D. Stuart Freeman > Georgia Institute of Technology -- D. Stuart Freeman Georgia Institute of Technology signature.asc Description: Digital signature
