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!
