Provide support for JsonValue in FSharp.Data about fleece HOT 14 CLOSED

As I mentioned in fsprojects/FSharp.Data#639 (comment) I think we'd have two versions, each working against a different JSON AST but with the same API and even much of the same implementation code.

I think the easiest way to do this is a combination of conditional compilation (i.e. #if FSHARPDATA), conditional references (i.e. <Reference Include="FSharp.Data" Condition="$(FSHARPDATA) != ''"> and maybe some type aliases.

If all goes ok the tests should need little to no changes (i.e. only some conditional compilation for namespaces)

from fleece.

I was reading the issue and I don't understand it very well, I think I'm missing something.
What's the value of having many JSon AST types?
Do they provide different functionality?
AFAIK JsonValue is defined in Fsharp.Data, isn't it better to change Fsharp.Data to use System.Json which seems to be standard in .NET?
If a high degree of integration is desired for a library, that library should prefer 'core' types over defining their own, I can see this compromise clearly in Fleece but what about Fsharp.Data?

from fleece.

System.Json isn't part of the core libraries and even seems deprecated? I think it was a Silverlight specific library at some point. I've never come across it until Fleece.

from fleece.

The thing is, there is no real standard. System.Json apparently was poised to be the standard in .NET 4.5 but MS dumped it in favor of Newtonsoft at the last moment. After that it got badly relegated, being only available in Silverlight and as a beta/deprecated NuGet package, though it is fully supported in Mono.

So Newtonsoft has become the de facto standard (it was the first one so it always was really). IIRC its AST is kinda ill-defined compared to System.Json or FSharp.Data, though I don't really remember the details and maybe it could be wrapped to make it more sensible. I'm also not fond of the amount of reflection and other complexity it contains. But the fact is that it's supported in all platforms now and is by far the most popular. And at least it has an AST (for example, last I checked ServiceStack.Text doesn't have one).

So maybe we should all (FSharp.Data, Fleece, all JSON libraries) just bite the bullet and use Newtonsoft's AST.

Scala has already standardized this with json4s, though many still reject it and not all JSON libs have adhered (e.g. Argonaut).

from fleece.

You read my mind, I was going to propose Newtonsoft's AST as well. I think it will provide better integration.

from fleece.

It's a real shame because System.Json does just about what a fundamental JSON lib has to do: provide a good AST and do parsing/serialization. It's not perfect, for example the AST is mutable and has ReadAs<T> methods that are partial and break parametricity (only where reflection is available). But otherwise it's very very simple compared to Newtonsoft.

About the FSharpPlus dependency: other than traverse and map I'm also using <*>. Sure we could embed them into Fleece, but then when writing serializers/parsers I use all of them again plus monad, >>=, etc so I take a dependency on FSharpPlus anyway. But if people insist on using something else to write their serializers/parsers it could be done, technically. Just as long as it doesn't break my code :)

from fleece.

Checkout the new version of FsControl. It has a tiny Operators module with some common definitions.
So you probably don't need F#+ anymore, unless you need extensions or types defined there.

from fleece.

On the other hand, the new version of F#+ has those tuple2, tuple3, ..., tupleN combinators which you are using there.
I wish the new F# version includes them.

from fleece.

Right, Fleece already uses many things from FSharpPlus and client code (at least mine) uses FSharpPlus too so while it is technically possible to remove the dependency it would just cause code duplication for IMHO little to no real gain.

from fleece.

The reason I even mention it is that we've been implementing services with F# scripts which makes you very much aware of all the dependencies.

from fleece.

@mausch I added support for FSharp.Data.JsonValue using conditional compilation symbol, but I'm not sure how to use that symbol for conditional references: eulerfx@835ef58

from fleece.

Thanks, I merged it to master and sorted out the details of "multitargeting" different ASTs/references.

I'm ready to release it but an issue popped up: both Fleece.dll and Fleece.FSharpData.dll use the same namespace Fleece. It's unlikely that a project would use both, but if it happened this would create a conflict, and F# doesn't seem to have anything like C#'s extern alias to resolve it. Do you know any way around this? Is it worth using separate namespaces?

from fleece.

I don't know of a way around this. I think situations where both are used
would be rare but a may arise during a transition period when switching
from one to the other. I would personally risk the clash to avoid a
separate namespace however.

On Mon, Sep 8, 2014 at 9:23 PM, Mauricio Scheffer [email protected]
wrote:

Thanks, I merged it to master and sorted out the details of
"multitargeting" different ASTs/references.

I'm ready to release it but an issue popped up: both Fleece.dll and
Fleece.FSharpData.dll use the same namespace Fleece. It's unlikely that a
project would use both, but if it happened this would create a conflict,
and F# doesn't seem to have anything like C#'s extern alias to resolve
it. Do you know any way around this? Is it worth using separate namespaces?

—
Reply to this email directly or view it on GitHub
#5 (comment).

from fleece.

I agree. Released to NuGet: https://www.nuget.org/packages/Fleece.FSharpData/
Thanks again!

from fleece.