source/app.d(51,37): Error: function dub.internal.utils.jsonFromFile (Path file, bool silent_fail = false) is not callable using argument types (Path, bool)

WTF?

Am 09.02.2017 um 22:20 schrieb Daniel Kozak:
> source/app.d(51,37): Error: function dub.internal.utils.jsonFromFile
> (Path file, bool silent_fail = false) is not callable using argument
> types (Path, bool)
>
> WTF?

Must be caused by Path meaning two different type definitions. The most likely cause is that by default the DUB sources use their own version of Path, while if vibe.d is available in the dependency graph, they will use the ones defined there instead.

But the error message is indeed awful.

Dne 9.2.2017 v 22:20 Daniel Kozak via Digitalmars-d napsal(a):

> source/app.d(51,37): Error: function dub.internal.utils.jsonFromFile (Path file, bool silent_fail = false) is not callable using argument types (Path, bool)
>
> WTF?
Problem is with multiple Path declaration, but with this error message it is really hard to find out which one. Maybe it would be better to show full names of symbol

On Thursday, 9 February 2017 at 21:31:48 UTC, Daniel Kozak wrote:
> Dne 9.2.2017 v 22:20 Daniel Kozak via Digitalmars-d napsal(a):
>
>> source/app.d(51,37): Error: function dub.internal.utils.jsonFromFile (Path file, bool silent_fail = false) is not callable using argument types (Path, bool)
>>
>> WTF?
> Problem is with multiple Path declaration, but with this error message it is really hard to find out which one. Maybe it would be better to show full names of symbol

please do submit an request for this,

Dne 9.2.2017 v 22:28 Sönke Ludwig via Digitalmars-d napsal(a):

> Am 09.02.2017 um 22:20 schrieb Daniel Kozak:
>> source/app.d(51,37): Error: function dub.internal.utils.jsonFromFile
>> (Path file, bool silent_fail = false) is not callable using argument
>> types (Path, bool)
>>
>> WTF?
>
> Must be caused by Path meaning two different type definitions. The most likely cause is that by default the DUB sources use their own version of Path, while if vibe.d is available in the dependency graph, they will use the ones defined there instead.
>
> But the error message is indeed awful.
Yes, btw it is impossible to build https://github.com/dlang/dub-registry right now because of this

Dne 9.2.2017 v 22:36 Stefan Koch via Digitalmars-d napsal(a):

> On Thursday, 9 February 2017 at 21:31:48 UTC, Daniel Kozak wrote:
>> Dne 9.2.2017 v 22:20 Daniel Kozak via Digitalmars-d napsal(a):
>>
>>> source/app.d(51,37): Error: function dub.internal.utils.jsonFromFile (Path file, bool silent_fail = false) is not callable using argument types (Path, bool)
>>>
>>> WTF?
>> Problem is with multiple Path declaration, but with this error message it is really hard to find out which one. Maybe it would be better to show full names of symbol
>
> please do submit an request for this,
It would be probably duplicate of this one https://issues.dlang.org/show_bug.cgi?id=9631

On Thursday, 9 February 2017 at 21:28:58 UTC, Sönke Ludwig wrote:
> Am 09.02.2017 um 22:20 schrieb Daniel Kozak:
>> source/app.d(51,37): Error: function dub.internal.utils.jsonFromFile (Path file, bool silent_fail = false) is not callable using argument types (Path, bool)
>>
>> WTF?
>
> Must be caused by Path meaning two different type definitions.

 I'll have to agree. Back in ... 2009? I was in a company where we were doing web development for a bit, and one curious error that came up was when trying to assign or work with the Date object. Seems the built in Date class wasn't the same as the Sql.Date that was being used (but had the same name). Apparently it took like 2 hours to figure out what was going on.

 In cases like these i really wish the structure of the class/struct had a hash or something (based on source or struct layout or something) to help differentiate it rather than just by name, and reverse lookup the exact file location(s) of where the struct in question comes from.

On Friday, 10 February 2017 at 02:53:50 UTC, Era Scarecrow
>  In cases like these i really wish the structure of the class/struct had a hash or something (based on source or struct layout or something)

They do have different full names, which includes the module name and uniquely differentiates them. The compiler knows it too, just isn't smart enough to actually display it in times like this.

On Friday, 10 February 2017 at 03:07:28 UTC, Adam D. Ruppe wrote:
> They do have different full names, which includes the module name and uniquely differentiates them. The compiler knows it too, just isn't smart enough to actually display it in times like this.

So maybe when the class name along can be ambiguous program it to give a full or non-ambiguous path for which class/structs they actually are? Seems like it would be a 1-2 line change...

On Friday, 10 February 2017 at 02:53:50 UTC, Era Scarecrow wrote:
> Seems the built in Date class wasn't the same as the Sql.Date that was being used (but had the same name). Apparently it took like 2 hours to figure out what was going on.

 Oh right forgot to mention one important detail. In Java the program compiled without errors; It was when it was trying to be used that it would crash unexpectedly. Refusing to compile is slightly better than crashing unexpectedly later.