interface is interface
Hello! import std.stdio; interface I { } interface B : I { void test(); } interface C : I { void test1(); } class A : B, C { override void test() {} override void test1() {} } void main() { A a = new A(); I b = cast(B)a; I c = cast(C)a; writeln(cast(void*)a, " ", cast(void*)b, " ", cast(void*)c); // 1EE1FE0 1EE1FE8 1EE1FEC assert (a is b); // OK assert (a is c); // FAIL WHY }
Problem with trying sample from doc page
Hi! I've been experimenting with D functions, and found this piece of code: // int abc(int delegate(long i)); int def(int function(long s)); void test() { int b = 3; abc( (long c) { return 6 + b; } ); // inferred to delegate def( (long c) { return c * 2; } ); // inferred to function } // On linux machine with [DMD64 D Compiler v2.065] it doesn't compile, giving me this error: test.d(10): Error: function test.def (int function(long s)) is not callable using argument types (long function(long c) pure nothrow @safe) Here DMD infers (long c) { return c * 2; } as long function(long c). And "def" definition doesn't match. Is that an error in the docs, or mayber I'm doing something wrong?
Re: Problem with trying sample from doc page
On Wednesday, 16 July 2014 at 15:12:58 UTC, Pavel wrote: Hi! I've been experimenting with D functions, and found this piece of code: // int abc(int delegate(long i)); int def(int function(long s)); void test() { int b = 3; abc( (long c) { return 6 + b; } ); // inferred to delegate def( (long c) { return c * 2; } ); // inferred to function } // On linux machine with [DMD64 D Compiler v2.065] it doesn't compile, giving me this error: test.d(10): Error: function test.def (int function(long s)) is not callable using argument types (long function(long c) pure nothrow @safe) Here DMD infers (long c) { return c * 2; } as long function(long c). And "def" definition doesn't match. Is that an error in the docs, or mayber I'm doing something wrong? Link to the doc is: http://dlang.org/expression#FunctionLiteral
D JSON (WAT?!)
Ok, let me start with the sample code: import std.stdio; import std.json; void main() { scope(failure) writeln("FaILED!!"); string jsonStr = `{ "name": "1", "type": "r" }`; auto parsed = parseJSON(jsonStr); string s = parsed["fail"].str; writeln(s == ""); writeln(s is null); writeln(s); } Running "rdmd app.d" doesn't produce any output. Can anyone explain such a behavior??? PS: Running dmd v2.065 on Linux x64.
Re: D JSON (WAT?!)
On Thursday, 24 July 2014 at 15:22:46 UTC, Adam D. Ruppe wrote: On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote: string s = parsed["fail"].str; Since there is no entry "fail" in the object, it returns a null JSON_VALUE pointer. Trying to get the string out of it is then seen as a null pointer access and kills the program. Check for null on a key before trying to get a value out. Ok, added: writeln(parsed["fail"] == null); Now compiler complains: Error: incompatible types for ((parsed.opIndex("fail")) == (null)): 'JSONValue' and 'typeof(null)' WAT?!
Re: D JSON (WAT?!)
On Thursday, 24 July 2014 at 15:31:30 UTC, Daniel Gibson wrote: Am 24.07.2014 17:29, schrieb Pavel: On Thursday, 24 July 2014 at 15:22:46 UTC, Adam D. Ruppe wrote: On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote: string s = parsed["fail"].str; Since there is no entry "fail" in the object, it returns a null JSON_VALUE pointer. Trying to get the string out of it is then seen as a null pointer access and kills the program. Check for null on a key before trying to get a value out. Ok, added: writeln(parsed["fail"] == null); Now compiler complains: Error: incompatible types for ((parsed.opIndex("fail")) == (null)): 'JSONValue' and 'typeof(null)' WAT?! "is" instead of "==" ? Nope, the compiler still complains.
Re: D JSON (WAT?!)
On Thursday, 24 July 2014 at 15:20:58 UTC, Justin Whear wrote: On Thu, 24 Jul 2014 15:15:36 +, Pavel wrote: Ok, let me start with the sample code: import std.stdio; import std.json; void main() { scope(failure) writeln("FaILED!!"); string jsonStr = `{ "name": "1", "type": "r" }`; auto parsed = parseJSON(jsonStr); string s = parsed["fail"].str; writeln(s == ""); writeln(s is null); writeln(s); } Running "rdmd app.d" doesn't produce any output. Can anyone explain such a behavior??? PS: Running dmd v2.065 on Linux x64. That's because it produces a segmentation fault, which rdmd masks for some reason. The `parsed["fail"]` should throw a range bounds exception-- not sure why it's not. Here's phobos code from github: /// Hash syntax for json objects. /// Throws $(D JSONException) if $(D type) is not $(D JSON_TYPE.OBJECT). ref inout(JSONValue) opIndex(string k) inout { enforceEx!JSONException(type == JSON_TYPE.OBJECT, "JSONValue is not an object"); return *enforceEx!JSONException(k in store.object, "Key not found: " ~ k); } Added in https://github.com/D-Programming-Language/phobos/commit/13fbd451bcca923cf8d1028495e58aa88cc7efeb Maybe phobos is not up to date for me???
Re: D JSON (WAT?!)
On Thursday, 24 July 2014 at 15:34:22 UTC, Ali Çehreli wrote: On 07/24/2014 08:29 AM, Pavel wrote: writeln(parsed["fail"] == null); Now compiler complains: Error: incompatible types for ((parsed.opIndex("fail")) == (null)): 'JSONValue' and 'typeof(null)' WAT?! Comparing against null should be done with the 'is' operator, not the == operator: if (x is null) Ali My compiler disagreed: app.d(8): Error: incompatible types for ((parsed.opIndex("fail")) is (null)): 'JSONValue' and 'typeof(null)'
Re: D JSON (WAT?!)
On Thursday, 24 July 2014 at 15:32:29 UTC, John Colvin wrote: On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote: Ok, let me start with the sample code: import std.stdio; import std.json; void main() { scope(failure) writeln("FaILED!!"); string jsonStr = `{ "name": "1", "type": "r" }`; auto parsed = parseJSON(jsonStr); string s = parsed["fail"].str; writeln(s == ""); writeln(s is null); writeln(s); } Running "rdmd app.d" doesn't produce any output. Can anyone explain such a behavior??? PS: Running dmd v2.065 on Linux x64. It's a bug in std.json (you should get a segfault, not no output at all) It is fixed now and I'm pretty sure it will be in 2.066 std.json has been improved a lot, but I would still recommend using http://vibed.org/api/vibe.data.json/ instead I'm pretty sure it's improving, but it has that "Java" disease, which is creating new Types, which are just wrappers for common types. Why don't just use Variant[string] for objects, and Variant[] for arrays. This way you won't be putting another layer of knowledge for those who work with std.json.
Re: D JSON (WAT?!)
On Thursday, 24 July 2014 at 15:42:58 UTC, Pavel wrote: On Thursday, 24 July 2014 at 15:38:06 UTC, John Colvin wrote: On Thursday, 24 July 2014 at 15:32:29 UTC, John Colvin wrote: On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote: Ok, let me start with the sample code: import std.stdio; import std.json; void main() { scope(failure) writeln("FaILED!!"); string jsonStr = `{ "name": "1", "type": "r" }`; auto parsed = parseJSON(jsonStr); string s = parsed["fail"].str; writeln(s == ""); writeln(s is null); writeln(s); } Running "rdmd app.d" doesn't produce any output. Can anyone explain such a behavior??? PS: Running dmd v2.065 on Linux x64. It's a bug in std.json (you should get a segfault, not no output at all) It is fixed now and I'm pretty sure it will be in 2.066 std.json has been improved a lot, but I would still recommend using http://vibed.org/api/vibe.data.json/ instead perhaps "bug" is too strong a word, but it was a deficiency that is now corrected. You will get an exception thrown now and everything should work how you expect. Maybe. But still it's not the way I expect, any time you check for non-existing property you must consider exception, which is very heavy to deal with in such a situation. I'd rather expect to get null, whenever I try to fetch non-existing property, and not an exception. That's purely my point, and I don't claim to be right in this way. It's up to Phobos maintainers to decide how to reprent JSON parsing results. Also that's why you just can't write: writeln("fail" in parsed); As JSONValue is just a wrapper: non-native, non-intuitive.
Re: D JSON (WAT?!)
On Thursday, 24 July 2014 at 15:38:06 UTC, John Colvin wrote: On Thursday, 24 July 2014 at 15:32:29 UTC, John Colvin wrote: On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote: Ok, let me start with the sample code: import std.stdio; import std.json; void main() { scope(failure) writeln("FaILED!!"); string jsonStr = `{ "name": "1", "type": "r" }`; auto parsed = parseJSON(jsonStr); string s = parsed["fail"].str; writeln(s == ""); writeln(s is null); writeln(s); } Running "rdmd app.d" doesn't produce any output. Can anyone explain such a behavior??? PS: Running dmd v2.065 on Linux x64. It's a bug in std.json (you should get a segfault, not no output at all) It is fixed now and I'm pretty sure it will be in 2.066 std.json has been improved a lot, but I would still recommend using http://vibed.org/api/vibe.data.json/ instead perhaps "bug" is too strong a word, but it was a deficiency that is now corrected. You will get an exception thrown now and everything should work how you expect. Maybe. But still it's not the way I expect, any time you check for non-existing property you must consider exception, which is very heavy to deal with in such a situation. I'd rather expect to get null, whenever I try to fetch non-existing property, and not an exception. That's purely my point, and I don't claim to be right in this way. It's up to Phobos maintainers to decide how to reprent JSON parsing results.
Re: D JSON (WAT?!)
On Thursday, 24 July 2014 at 15:48:32 UTC, Edwin van Leeuwen wrote: On Thursday, 24 July 2014 at 15:42:58 UTC, Pavel wrote: On Thursday, 24 July 2014 at 15:38:06 UTC, John Colvin wrote: On Thursday, 24 July 2014 at 15:32:29 UTC, John Colvin wrote: On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote: Ok, let me start with the sample code: import std.stdio; import std.json; void main() { scope(failure) writeln("FaILED!!"); string jsonStr = `{ "name": "1", "type": "r" }`; auto parsed = parseJSON(jsonStr); string s = parsed["fail"].str; writeln(s == ""); writeln(s is null); writeln(s); } Running "rdmd app.d" doesn't produce any output. Can anyone explain such a behavior??? PS: Running dmd v2.065 on Linux x64. It's a bug in std.json (you should get a segfault, not no output at all) It is fixed now and I'm pretty sure it will be in 2.066 std.json has been improved a lot, but I would still recommend using http://vibed.org/api/vibe.data.json/ instead perhaps "bug" is too strong a word, but it was a deficiency that is now corrected. You will get an exception thrown now and everything should work how you expect. Maybe. But still it's not the way I expect, any time you check for non-existing property you must consider exception, which is very heavy to deal with in such a situation. I'd rather expect to get null, whenever I try to fetch non-existing property, and not an exception. You can turn your json object into an AA object and then use in to check for existence (I know it is not very intuitive): JSONValue[string] jsonAA = parsed.object; if ( "fail" in jsonAA ) s = jsonAA["fail"].str; That's purely my point, and I don't claim to be right in this way. It's up to Phobos maintainers to decide how to reprent JSON parsing results. Guess what, here's a new snippet: import std.stdio; import std.json; void main() { scope(failure) writeln("FaILED!!"); string jsonStr = `{ "name": "1", "type": "r" }`; auto parsed = parseJSON(jsonStr).object; writeln("fail" in parsed); } Output is: null WAT?! Ofcourse, writing like: writeln(cast(bool)("fail" in parsed)); Produces "false"... but why on earth boolean expression would output null? PS: Sorry, for such an emotional boom, I'm so frustrated right now.
Re: D JSON (WAT?!)
On Thursday, 24 July 2014 at 15:59:52 UTC, Daniel Gibson wrote: Am 24.07.2014 17:54, schrieb Pavel: Guess what, here's a new snippet: import std.stdio; import std.json; void main() { scope(failure) writeln("FaILED!!"); string jsonStr = `{ "name": "1", "type": "r" }`; auto parsed = parseJSON(jsonStr).object; writeln("fail" in parsed); } Output is: null WAT?! Ofcourse, writing like: writeln(cast(bool)("fail" in parsed)); Produces "false"... but why on earth boolean expression would output null? PS: Sorry, for such an emotional boom, I'm so frustrated right now. Relax :-) And see http://dlang.org/hash-map.html "in" doesn't just return if something is in a map. If it is, it returns a pointer to the value, otherwise null. Thus null. Cheers, Daniel Thanks to all you folks who explained "in" operator for me. My bad. Let's focus on the real problem, which is JSON wrapper class. Is it needed? Wouldn't it be better to get AA from parseJSON?
Re: D JSON (WAT?!)
On Thursday, 24 July 2014 at 16:02:12 UTC, H. S. Teoh via Digitalmars-d-learn wrote: On Thu, Jul 24, 2014 at 03:54:20PM +, Pavel via Digitalmars-d-learn wrote: [...] Guess what, here's a new snippet: import std.stdio; import std.json; void main() { scope(failure) writeln("FaILED!!"); string jsonStr = `{ "name": "1", "type": "r" }`; auto parsed = parseJSON(jsonStr).object; writeln("fail" in parsed); } Output is: null WAT?! Ofcourse, writing like: writeln(cast(bool)("fail" in parsed)); Produces "false"... but why on earth boolean expression would output null? It's not a boolean expression. The 'in' operator returns a pointer. Rationale: avoid double lookups, for example: if (auto ptr = "key" in assocArray) { doSomething(*ptr); } T Thanks once again. Now I finally get this thing done with code like this: import std.stdio; import std.json; void main() { scope(failure) writeln("Failure!!"); string jsonStr = `{ "name": "1", "type": "r" }`; auto parsed = parseJSON(jsonStr).object; auto found = "fail" in parsed; if (found !is null) { string s = found.str; writeln(s); } else { writeln("No such key"); } } Still focus on wrapper class discussion :)
Re: D JSON (WAT?!)
On Thursday, 24 July 2014 at 16:09:25 UTC, Justin Whear wrote: On Thu, 24 Jul 2014 16:04:01 +, Pavel wrote: Thanks to all you folks who explained "in" operator for me. My bad. Let's focus on the real problem, which is JSON wrapper class. Is it needed? Wouldn't it be better to get AA from parseJSON? The following are valid JSON: auto json1 = parseJSON(`1`); auto json2 = parseJSON(`"foo"`); auto json3 = parseJSON(`[1, 2, 3]`); None of these fit naturally into an JSONValue[string] return type. Oh, man! You're wrong!!! Read: http://www.json.org/, and try putting "1" or "foo" as JSON string here: http://jsonlint.com/
Re: D JSON (WAT?!)
On Thursday, 24 July 2014 at 18:49:27 UTC, Ary Borenszweig wrote: On 7/24/14, 1:58 PM, Justin Whear wrote: On Thu, 24 Jul 2014 13:49:27 -0300, Ary Borenszweig wrote: Nope, a JSON can only be an array or an object (hash). Ary, can you point out the place in the spec where this is specified? Not to be pedantic, but the spec only seems to define a "JSON value", not a "JSON document". You are right, my bad. According to Wikipedia (which has links to RFCs): Early versions of JSON (such as specified by RFC 4627) required that a valid JSON "document" must consist of only an object or an array type—though they could contain other types within them. This restriction was relaxed starting with RFC 7158, so that a JSON document may consist entirely of any possible JSON typed value. Sorry, Justin Whear, you were right, I was wrong. Yep, now it's pretty clear why there is JSONValue.
Re: D JSON (WAT?!)
On Thursday, 24 July 2014 at 16:09:25 UTC, Justin Whear wrote: On Thu, 24 Jul 2014 16:04:01 +, Pavel wrote: Thanks to all you folks who explained "in" operator for me. My bad. Let's focus on the real problem, which is JSON wrapper class. Is it needed? Wouldn't it be better to get AA from parseJSON? The following are valid JSON: auto json1 = parseJSON(`1`); auto json2 = parseJSON(`"foo"`); auto json3 = parseJSON(`[1, 2, 3]`); None of these fit naturally into an JSONValue[string] return type. Now we figured it out about JSON, but in that case: Why not just use std.variant.Variant construct instead of JSONValue?
Re: D JSON (WAT?!)
On Thursday, 24 July 2014 at 16:09:25 UTC, Justin Whear wrote: On Thu, 24 Jul 2014 16:04:01 +, Pavel wrote: Thanks to all you folks who explained "in" operator for me. My bad. Let's focus on the real problem, which is JSON wrapper class. Is it needed? Wouldn't it be better to get AA from parseJSON? The following are valid JSON: auto json1 = parseJSON(`1`); auto json2 = parseJSON(`"foo"`); auto json3 = parseJSON(`[1, 2, 3]`); None of these fit naturally into an JSONValue[string] return type. auto json4 = parseJSON(`true`); This is a valid JSON also. I know that as per JSON spec there's no boolean type specified, only separate true and false values, which are specified as type in http://dlang.org/library/std/json/JSON_TYPE.html, so I guess the only way to check boolean in JSONValue it is to write: if (json4.type == JSON_TYPE.True) { } else { } Am I right?
d plugin for Intelij Idea debuging support
Hello! Is there any debuging support for Intelij Idea's D plugin? Thanks!