JSON
We all know what it is.
In ECMAScript 4, there's a JSON proposal:
Object.prototyp e.toJSONString
String.prototyp e.parseJSON
The current proposal, String.prototyp e.parseJSON, returns an object.
This is very poor design. It's worse than Date.parse(s), which returns
a Number (not a Date).
The current proposal, Object.prototyp e.toJSONString, complicates
objects with responsibility that they should not necessarily have. It
will be easy to misuse. It will conflate Object.prototyp e with
implementation details possibly leaking into places they shouldn't.
Instead of keeping reduced access, it maximizes access. It does not
allow the functionality to be tested and debugged independently.
If these features go in the language, implementations and library
authors will be required to handle this method for all objects, of any
type, forever. The change will be permanent and unretractable.
This feature is not critical; it can be added at any time. The flip
side to that is that once added, it cannot be removed. ever.
Alternatives
1. A built in JSON object
A built in JSON object would keep the JSON serialization/parsing
independent. It will be easy to learn, easy to extend, easy to read
and maintain code that uses it, and it will fulfill the requirements.
It won't complicate Object.prototyp e.
JSON.parseFromS tring( s );
JSON.toJSONStri ng( jsonObject, pretty );
2. A JSON Interface
A JSON interface can be implemented to allow a class to have the
JSON Methods as instance methods.
function parseFromString ( s, pretty ) : <T>
function toJSONString( );
An JSON interface could instead be simply a tagging interface.
If the object supports the JSON interface, it could be used with a
JSON static JSON.parseFromS tring( s, type );, where type is something
like Map.
Test this out with three different types, say: Object, Map, and
Array.
If JSON is in the langauge, there will need to be some sort of
JSONError Error object.
23  3211 
<dh**********@g mail.comwrote:
JSON
We all know what it is.
A subset of javascript's Object/Array literal notation used for data
representation/exchange.
In ECMAScript 4, there's a JSON proposal:
Object.prototyp e.toJSONString
String.prototyp e.parseJSON
The current proposal, String.prototyp e.parseJSON, returns an
object. This is very poor design. It's worse than
Date.parse(s), which returns a Number (not a Date).
Why, given that part of the point of JSON is that it can be directly
translated into object structures in jvascrtip?
The current proposal, Object.prototyp e.toJSONString,
complicates objects with responsibility that they
should not necessarily have.
Why shouldn't an object have a specialised serialisation method?
It will be easy to misuse.
An example of this "misuse"?
It will conflate Object.prototyp e with implementation
details possibly leaking into places they shouldn't.
Instead of keeping reduced access, it maximizes access.
It does not allow the functionality to be tested and
debugged independently.
If these features go in the language, implementations and
library authors will be required to handle this method
for all objects, of any type, forever. The change will
be permanent and unretractable.
This feature is not critical; it can be added at any time.
The flip side to that is that once added, it cannot be
removed. ever.
There are many assertions here but not one substantial argument to back
any of them up. Between ECMA 262 2nd edition and 3rd edition the object
prototype gained hasOwnProperty, propertyIsEnume rable and isPrototypeOf
methods with no negative impact. Adding methods to the object prototype
does not necessarily have any impact on anything else at all.
Alternatives
1. A built in JSON object
Because JSON translates directly into structures of javascript
objects/arrays it makes no sense to attempt to create a specific JSON
object.
<snip>
If JSON is in the langauge, there will need to be
some sort of JSONError Error object.
A JAON parsing error seems appropriate, though javascript's errors need
a great deal of additional work before they become that usable.
Richard. dh**********@gm ail.com wrote:
In ECMAScript 4, there's a JSON proposal:
Object.prototyp e.toJSONString
String.prototyp e.parseJSON
Good idea.
The current proposal, String.prototyp e.parseJSON, returns an object.
This is very poor design.
IBTD. As JSON is a subset of Object/Array literal notation, I don't see a
reason why the result should *not* be an object.
It's worse than Date.parse(s), which returns a Number (not a Date).
Date.parse(s) is more flexible than it would be if it returned a Date object
reference. If the number bothers you, you are free to use `new Date(s)'
instead or use the return value of Date.parse(s) as argument for the
constructor.
The current proposal, Object.prototyp e.toJSONString, complicates
objects with responsibility that they should not necessarily have. It
will be easy to misuse. It will conflate Object.prototyp e with
implementation details possibly leaking into places they shouldn't.
Why would that be? Those will be built-in methods then, and most certainly
they will have the DontEnum attribute.
Instead of keeping reduced access, it maximizes access.
More important is that such methods would finally provide efficient
implementation-independent means.
It does not allow the functionality to be tested and debugged independently.
Did you care to debug toString(), toValue() aso. to date?
[...]
An JSON interface could instead be simply a tagging interface.
If the object supports the JSON interface, it could be used with a
JSON static JSON.parseFromS tring( s, type );, where type is something
like Map.
Test this out with three different types, say: Object, Map, and
Array.
Please forgive my ignorance, what would Map be?
If JSON is in the langauge, there will need to be some sort of
JSONError Error object.
That would be useful, but not necessary.
PointedEars
--
var bugRiddenCrashP ronePieceOfJunk = (
navigator.userA gent.indexOf('M SIE 5') != -1
&& navigator.userA gent.indexOf('M ac') != -1
) // Plone, register_functi on.js:16
On Oct 22, 10:49 am, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:
dhtmlkitc...@gm ail.com wrote:
In ECMAScript 4, there's a JSON proposal:
Object.prototyp e.toJSONString
String.prototyp e.parseJSON
Good idea.
The current proposal, String.prototyp e.parseJSON, returns an object.
This is very poor design.
IBTD. As JSON is a subset of Object/Array literal notation, I don't see a
reason why the result should *not* be an object.
Objects are used for collections. There are no other collection types
in ES3.
Objects are used for other things than collections, most of the time.
The conflation of Object and Hashtable causes problems in ES. Adding
toJSONString further complicates Objects with more responsibility.
It's worse than Date.parse(s), which returns a Number (not a Date).
Date.parse(s) is more flexible than it would be if it returned a Date object
reference. If the number bothers you, you are free to use `new Date(s)'
instead or use the return value of Date.parse(s) as argument for the
constructor.
The return type is incorrect. Even in Java's Date object (which has
it's problems) Date.parse returns a Date (normal). The problem is that
you can't parse localized dates based on a string. It's impossible.
The current proposal, Object.prototyp e.toJSONString, complicates
objects with responsibility that they should not necessarily have. It
will be easy to misuse. It will conflate Object.prototyp e with
implementation details possibly leaking into places they shouldn't.
Why would that be? Those will be built-in methods then, and most certainly
they will have the DontEnum attribute.
W/A JSON Object, You could add it yourself w/only a few lines of code:
unit ThomasJSON {
internal package ThomasJSON {
Object.prototyp e.toJSONString = function () { return
JSON.toJSONStri ng(this) };
Object.prototyp e.propertyIsEnu merable("toJSON String", false);
}
}
In your code:
use unit ThomasJSON "http://example.com";
Instead of keeping reduced access, it maximizes access.
More important is that such methods would finally provide efficient
implementation-independent means.
It does not allow the functionality to be tested and debugged independently.
Did you care to debug toString(), toValue() aso. to date?
What is aso?
valueOf should produce testable, consistent results on Date objects
Date.prototype. toString providing a formatting dependency is a
problem. It is not localized.
toDateString and toTimeString should be on a DateFormatter class.
toString should be for diagnostic info.
[...]
An JSON interface could instead be simply a tagging interface.
If the object supports the JSON interface, it could be used with a
JSON static JSON.parseFromS tring( s, type );, where type is something
like Map.
Test this out with three different types, say: Object, Map, and
Array.
Please forgive my ignorance, what would Map be?
Map<T,Tis a data structure. It's in ES4. Long overdue.
If JSON is in the langauge, there will need to be some sort of
JSONError Error object.
That would be useful, but not necessary.
Depends what 'necessary' means. A lot of necessary things
(collections) are missing in ES3, yet we manage.
Constructor's based on Error (subclass) in ES3 doesn't really work
that well.
PointedEars
On Oct 22, 3:09 pm, "dhtmlkitc...@g mail.com" <dhtmlkitc...@g mail.com>
wrote:
Objects are used for collections. There are no other collection types
in ES3.
Objects are used for other things than collections, most of the time.
The conflation of Object and Hashtable causes problems in ES.
In all completely object-oriented languages, like JavaScript, isn't it
necessary that hashes are objects?
Adding
toJSONString further complicates Objects with more responsibility.
If the line of purity has already been crossed, and objects have more
responsibilitie s than they should, what exactly is _so_ offensive with
one more? That is meant as a genuine question. Will the existence of
the toJSONString property make day-to-day programming with JavaScript
more difficult or different than it is now?
unit ThomasJSON {
Is "unit" a new keyword for ES4?
Map<T,Tis a data structure. It's in ES4. Long overdue.
Is the "<T,T>" optional for those that don't want to use types?
We are really headed towards Java, aren't we? The sad thing is some
poor JavaScript programmers, who don't want to program in Java, are
going to be told to program the Java way once ES4 is available.
Peter
Peter Michaux wrote:
On Oct 22, 3:09 pm, "dhtmlkitc...@g mail.com" wrote:
<snip>
>unit ThomasJSON {
Is "unit" a new keyword for ES4?
And say goodbye to any hope of back-compatibility with current versions
if it is, as up until now "unit" had been a valid Identifier, and one I
use quite often as I use JS object reprehensions of commercial
buildings, which are sub-divided into units.
We are going to end up with another MIME type hack here.
>Map<T,Tis a data structure. It's in ES4. Long
overdue.
Is the "<T,T>" optional for those that don't want to
use types?
We are really headed towards Java, aren't we?
Unfortunately it has looked that way for some time. Java already exists
so I don't see the point in trying to create another. And it is a near
certainty that the end result actually will be the inferior Java that
javascript is already often mistakenly perceived as being.
The sad thing is some poor JavaScript programmers, who
don't want to program in Java, are going to be told to
program the Java way once ES4 is available.
What makes you think ES4 will offer the choice?
Richard.
On Oct 22, 4:10 pm, Peter Michaux <petermich...@g mail.comwrote:
On Oct 22, 3:09 pm, "dhtmlkitc...@g mail.com" <dhtmlkitc...@g mail.com>
wrote:
Objects are used for collections. There are no other collection types
in ES3.
Objects are used for other things than collections, most of the time.
The conflation of Object and Hashtable causes problems in ES.
In all completely object-oriented languages, like JavaScript, isn't it
necessary that hashes are objects?
A HashMap is an Object, an Object is not a HashMap. An object might be
a Menu. A Menu is not a HashMap. Too much responsibility for a Menu.
It violates most general programming principles like cohesion, SRP. It
is a problem with the ES3-.
Adding
toJSONString further complicates Objects with more responsibility.
If the line of purity has already been crossed, and objects have more
responsibilitie s than they should, what exactly is _so_ offensive with
one more? That is meant as a genuine question. Will the existence of
the toJSONString property make day-to-day programming with JavaScript
more difficult or different than it is now?
Getting away from object as a hashtable is the right direction.
unit ThomasJSON {
Is "unit" a new keyword for ES4?
Map<T,Tis a data structure. It's in ES4. Long overdue.
Is the "<T,T>" optional for those that don't want to use types?
Not optional, however,
<Object,Objec t>
- or -
<String,Objec t>
We are really headed towards Java, aren't we? The sad thing is some
poor JavaScript programmers, who don't want to program in Java, are
going to be told to program the Java way once ES4 is available.
That is false.
ES4 is backwards compatible.
Peter
On Oct 22, 6:03 pm, "dhtmlkitc...@g mail.com" <dhtmlkitc...@g mail.com>
wrote:
On Oct 22, 4:10 pm, Peter Michaux <petermich...@g mail.comwrote:O n Oct 22, 3:09 pm, "dhtmlkitc...@g mail.com" <dhtmlkitc...@g mail.com>
We are really headed towards Java, aren't we? The sad thing is some
poor JavaScript programmers, who don't want to program in Java, are
going to be told to program the Java way once ES4 is available.
That is false.
ES4 is backwards compatible.
I meant told by their managers, not by the ES4 spec writers.
Peter
On Oct 22, 4:01 pm, "Richard Cornford" <Rich...@litote s.demon.co.uk>
wrote:
dhtmlkitc...@gm ail.com wrote:
On Oct 22, 12:33 am, Richard Cornford wrote:
dhtmlkitc...@gm ail.com wrote:
<snip>
Integer.parseIn t <-- what should this return?
No such construct exists in javascript as there is no Integer object
and - parseInt - is a global function.
The example was taken from Java, to illustrate the concept that
XXX.parse is usually expected to return an XXX.
parseInt should be a Number function, not global.parseInt .
Number.parseInt
BTW, global is accessible in ES4.
Date.parse <-- what should this return?
A 'static' method of the Date constructor might be expected to return
something that was date related.
Like a date string? A Number? How about...
A Date ?
Ding, ding, ding!
now,
String.parseJSO N <-- should return what, a String?
Wasn't it - String.prototyp e.parseJSON - that you were objecting to? An
instance method of String object might be executed to turn that string
into anything. As JSON is a structure consisting of and object or array
with optional nested descendants then that is the likely result.
Why is adding the parse method to String correct?
Should the String constructor be morphed into a parser?
>The current proposal, Object.prototyp e.toJSONString,
complicates objects with responsibility that they
should not necessarily have.
Why shouldn't an object have a specialised serialisation
method?
Why should it?
Precedence would be a good enough reason, as JavaScript(tm) already
has - toSource - method on objects. All this adds is another form of
serialisation, and one that has obvious practical applications.
JavaScript -- not ES. It's a really old feature, and only Moz/NS4.
While the feature may have practical applications, such applications
are quite limited. Limited to what? Well, mostly to Data Structure.
Object should not always have data structure functionality. Only data
structures should. A Menu, could, for example, be converted to a Data
Structure, or could be so implemented. This would be a design
decision.
If it needs one, it can get it independently.
Maybe, but not a native code (so relatively fast) method.
It could define it's own
method for serialization. Not all objects need this.
Much as objects don't need - toSource - but don't suffer for having it.
toSource is limited to Spidermonkey, AFAIK.
toJSONString will be an ES4 standard.
It will be easy to misuse.
An example of this "misuse"?
HTMLInputElemen t.prototype.toJ SONString = getPWD;
There is plenty of scope for doing stupid things with the language as it
is.
Exactly! JavaScript lets you do all sorts of things.
"foo".prop
new Script("true");
"foo".big() ;
So why add another? And besides, toJSONString would be really useful
in a lot of cases. I realize that, really. But, at the same time, I
don't need it on my Tooltip.
Any of the misuses of for-in loop, or closures
would seem not as bad.
Which misuses?
Like the Power Constructor, the Module pattern. These things can and
are often used to make really strange and confusing code. There are
plenty of F/E devs who struggle trying to apply OO concepts to JS and
make judgement calls that create problems down the road.
>
>It will conflate Object.prototyp e with implementation
details possibly leaking into places they shouldn't.
Instead of keeping reduced access, it maximizes access.
It does not allow the functionality to be tested and
debugged independently.
>If these features go in the language, implementations and
library authors will be required to handle this method
for all objects, of any type, forever. The change will
be permanent and unretractable.
>This feature is not critical; it can be added at any time.
The flip side to that is that once added, it cannot be
removed. ever.
There are many assertions here but not one substantial
argument to back any of them up. Between ECMA 262 2nd
edition and 3rd edition the object prototype gained
hasOwnProperty, propertyIsEnume rable and isPrototypeOf
methods with no negative impact. Adding methods to the
object prototype does not necessarily have any impact
on anything else at all.
propertyIsEnume rable attempts, but fails in addressing the
problem of determining if a property is enumerable. It is
broken, as defined by ECMA-262.
You have said that before, but still have not posted any demonstration
of this supposed brokenness.
function b() {}
b.prototype.pie = "yes"; // enumerable prop.
var i = new b;
i.propertyIsEnu merable('pie'); // Well, what do you think?
for(var prop in i)
alert(prop); // will it alert "pie"?
What went wrong?
propertyIsEnume rable does not check the prototype chain, but for-in
does.
That is a bug.
The JScript bug eliminates any possibility of this method
being suitable for cross-browser use.
Which JScript bug? The one where - dontEnum - attributes are inherited
through the prototype chain when they should not be?
Yes, well, *mostly* the bug itelf is incosistent.
({prototype:1}) .propertyIsEnum erable('prototy pe'); // well, what does
JScript think?
(Function()).pr opertyIsEnumera ble('prototype' ); // well, what does
JScript think?
Objects need to deal with enumeration;
they're stuck with this
responsibility. This is is a problem.
It is not a problem. It has never been feasible to directly use
javascript objects as storage faculties for mapping arbitrary string
keys to values. The 'safe' set of possible keys in such a context don't
suffer from enumeration issues even in IE browsers.
All JScript bugs aside, Object is a generic type. HashMap, or
Map<String,Obje ct>, is specific. It says: I'm a data structure.
isPrototypeOf is useless/harmless. Can't be removed,
though.
As useless/irrelevant as - instanceof -.
Well, instanceof was there first. In ES4, it will work across frames.
toJSONString would not be so benign.
Why not, it would do no harm if not used, and if used then there would
presumably be some reason for using it.
It will be used. A lot, I think.
It's almost as bad is Object enumeration.
What is "bad" about object enumeration?
Enumeration has nothing to do with Object as a type. The feature
causes problems that have been the topic of discussion for years.
>
Or maybe worse. It means that every object is, by
default, not just a data structure, but a data structure that
also supports a specialized (or default) serialization.
Which is already the reality for JavaScript(tm) and that doesn't seem to
have resulted in any problems.
I've had my share of problems with this. Mostly related to the JScript
bug.
How in any way, is it justified?
Expedience, in the face of a growing use of JSON as a data exchange
medium, and particularly for transmission between HTTP clients and
servers.
JSON is not the panacea, for those who think it is, a native JSON
object will provide the same functionality, and will do nothing other
than provide such functionality.
Maybe 2% of all objects will need serialization at most.
Maybe, maybe not. What of it, I don't thing I have ever used
propertyIsEnume rable in production code but no objects have suffered for
having that unused method?
Besides being misnamed propertyIsEnume rable is broken.
for example:
x.toJSONString( );
if x is an instance of
function Widget() {
_name : "widget_" + widget.instance s.length;
}
Well, then you have to filter out the _name property in your
serialize method.
Why? What is it doing there if you don't want it included in the
serialisation, or if you don't want it why use the prototype
toJSONString method? You are the one doing the programming so program
the system to be what you want it to be.
Because it means that by default, Widget MUST tackle this
responsibility. Widget is Serializable, even if I don't want it to be,
I, as a programmer, have had that right taken away. That sucks.
>Alternatives
> 1. A built in JSON object
Because JSON translates directly into structures of javascript
objects/arrays it makes no sense to attempt to create a specific
JSON object.
JSON is a subset of JavaScript
Yes, a restriction of the nature of property name declarations in the
object literal strings and the types of values that may be assigned to
properties.
JSON translates into JS structures.
Which is what we are doing, taking a JSON string and getting a
javascript object.
JS Structures do not translate to JSON.
They can (or the whole thing would be a non-starter). All you are saying
is that objects can be created that will not translate well. And they
can, but that does not mean that rational programmers will create such
objects.
A Tooltip.show() method seems pretty rational to me. What does that
have to do with data structures?
>
It is not justified in ES3.
Adding serialization capabilities to every object creates
unnecessary complications. Each type of object has to deal
with this.
More like the serialisation process has to be able to deal with (in some
predetermined manner) all possible javascript objects. But that is just
a mater of specification.
Exactly. The serialization has to, and if it doesn't the programmer
has to provide it.
I can see it now, people will want next a way to set a serializable
flag on their properties to make things easier.
How would you serialize a Callable, a subclassed string,
an HTMLInputElemen t?
HTMLInputElemen t are not required to have prototype chins or inherit
form Object.protoype so they are irrelevant in the general case. Other
objects have properties with attributes and values regardless of their
'type'.
Not required, but they do, in many browsers. In those cases, it will
be required to deal with serialization.
And Callable is an Object, and a subc'd String is a String.
How is any of the above justified?
How is adding JSON methods to all objects justified over adding a
separate Class/Object to handle serialization?
<snip>
How is any of what justified? The proposed methods are an expedient or
harmless addition to the group of methods already on the pertinent
prototypes.
Not harmless when my Tooltip has to be responsible for serializing
itself.
Before having a JSON class implemented, I'd like to see three basic
types supported by a JSON object (like Map, et c).
a JSON Object would do:
serialize
deserialize
For those interested, Robert Sayre is implementing some JSON object
support in Mozilla, something along the lines of Caja.
Garrett
>
Richard.
On Oct 22, 7:08 pm, "dhtmlkitc...@g mail.com" <dhtmlkitc...@g mail.com>
wrote:
[snip about propertyIsEnume rable bug]
[snip about IE for-in enumeration bug]
[snip about object enumeration is a bad idea]
[snip about object serialization should not be an object property]
[snip about propertyIsEnume rable bug]
[snip about propertyIsEnume rable bug]
[snip about object serialization should not be an object property]
[snip about object enumeration is a bad idea]
[snip about IE for-in enumeration bug]
[snip about object serialization should not be an object property]
[snip about IE for-in enumeration bug]
[snip about object enumeration is a bad idea]
It's starting to be a ball of confusion which are the real problem
that need fixing and which are stylistic "separation of concerns"
issues. Your recommendations for ES3 to ES4 change have not been
separated. ;-) The real problems need the most attention. Consensus
will likely not be reached on stylistic issues.
I can see that the propertyIsEnume rable and the IE for-in bug seem to
be legitimate problems.
I've never had a problem with the for-in loop. I suppose that means
that when using an object as a hash that is subsequently enumerated
with for-in in IE, I have never added a "prototype" hash key. Is that
what this boils down to? This definitely seems to be something that
should be fixed.
It may be that most people don't really care if parseJSON is a
property of String or String.prototyp e or some JSON object. I know
that for functionality like serialization I care most that the
implementations work as specified. The JavaScript language is
considered by most to be a mess and there is no chance of attaining
any purity so where the JSON functions live is not so important to me.
If API structure was something that I allowed to bother me daily I'd
have popped by now working with JavaScript.
I definitely recommend dropping your recommended change from
propertyIsEnume rable to isPropertyEnume rable. If the target is moving,
the browser makers will never all hit it at the same time or ever.
This naming issue is completely superficial and detracts from other
more important and numerous recommendations perhaps to the point that
all recommendations will be ignored.
Peter
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: George Jempty |
last post by:
In my journal anyway:
"JSON: Javascript Unusable by the Client"
http://slashdot.org/~scriptify/journal/103074
|
by: G Matthew J |
last post by:
http://htmatters.net/htm/1/2005/07/evaling-JSON.cfm
This is more or less in response to Mr Crockford's admonition a few
months ago, "fork if you must". Ironically, although in that usenet
post he calls what I am suggesting "brittle", his own Javascript JSON
parser is not valid JSON, but rather conforms to my proposed variation
on JSON!! With an identifier prepended to the front of the JSON block,
and function literals as values: see...
|
by: Luke Matuszewski |
last post by:
Welcome
As suggested i looked into JSON project and was amazed but...
What about cyclical data structures - anybody was faced it in some
project ?
Is there any satisactional recomendation...
PS i am ready to use JSON as data/object interchange when using AJAX
and my J2EE project - because it is easier to traverse the JavaScript
object than its XML representation (so of course may argue).
|
by: Kevin Newman |
last post by:
Hello,
I noticed that the JavaScript library for JSON posted on json.org
(http://www.json.org/json.js) is modifying Object.prototype (adding a
method - toJSONString). I thought this was considered bad practice
because it can disrupt the use of for in loops on Objects.
Am I incorrect?
Thanks,
|
by: Adam |
last post by:
I'm trying to retrieve some values from a json object, but instead it's
giving me the property name. For example:
var json = { "glossary": { "title": "example glossary" } };
console.log(json);
alert(json.glossary.title);
for (var x in json) { console.log(x); alert(x.title); }
This will show me the json object in the console with glossary and
title underneath it. When the alert for json.glossary.title fires, it
| | |
by: ChrisO |
last post by:
I've been pretty infatuated with JSON for some time now since
"discovering" it a while back. (It's been there all along in
JavaScript, but it was just never "noticed" or used by most until
recently -- or maybe I should just speak for myself.)
The fact that JSON is more elegant goes without saying, yet I can't
seem to find a way to use JSON the way I *really* want to use it: to
create objects that can be instantated into multiple...
|
by: Jon Paal [MSMD] |
last post by:
using json like
( {"Records": , "RecordCount":"1" } )
and jquery like:
$.ajax({
....
success: function(json, status) {
|
by: Lasse Reichstein Nielsen |
last post by:
Max <adsl@tiscali.itwrites:
Not really. It shows that a particularly naïve implementation
of a conversion from XML to JSON doesn't work well.
What if the conversion of
<e>
some
|
by: crocodilu2008 |
last post by:
JSON vs. XML
JSON and XML are basically used for the same purpose—to represent and interchange data. I'll try to show you why you might want to use JSON rather than XML in an AJAX context by showing you an example of how an data class (actually, a list of PHP documentation pages) might be represented, first in XML. and then in JSON. This side-by-side comparison should let you begin to understand how to represent data in JSON. The XML version:...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
| | |
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
