LanguageExt.Http & LanguageExt.Json

[micmarsh]

Hello Everyone!

I figured I'd share a couple of libraries I've been working on open-sourcing, spun off from small local experiments with V5

• LanguageExt.Http, which I've shared here before but now has an "official" (0.1.0 at least) nuget release and is probably more generally useful now due to the below library
• LanguageExt.Json provides basic json (de/)serialization wrappers, but is really specialized around providing composable tools for querying deeply-nested json structures without having to deserialize giant nested objects.

I think each respective README will do a decent job of elaborating on the details. If these are interesting to anyone, please let me know what you think!

@louthy with both of these I did hijack the LanguageExt namespace, mostly to make static imports easier to write. Please let me know if this convention is okay, or if it's something we want to nip in the bud and discourage right now while the LanguageExt ecosystem is still young.

[StefanBertels]

There is a nuget feature to block third party publishers from using a prefix:
https://learn.microsoft.com/en-us/nuget/nuget-org/id-prefix-reservation

IMO it would be better to use this and therefore allow more trust into packages via individual namespaces. Sadly there are already other packages with "LanguageExt" prefix. This would require to use a new package prefix (for v5). What if @louthy later wants to publish some "official" package for Http or Json?

A different question is what namespace one should use. For libraries by @louthy this should still be LanguageExt for compatibility -- even if the packages would have different names.

IMO a restrained strategy (different namespace) is better. This would allow enabling new types and features explicitly in projects/files.
It's easy to have a default using or using static in project files so there is no need to add it in every file. Here's an example I use in my csproj files:

<ItemGroup>
    <Using Include="LanguageExt" />
    <Using Include "LanguageExt.Prelude" Static="True" />
</ItemGroup>

Why not use Micmarsh.LanguageExt.Http as package name and as namespace?

This is enough to make it easy to use it in the same way in the whole project:

<ItemGroup>
    <Using Include="Micmarsh.LanguageExt" />
    <Using Include "Micmarsh.LanguageExt.Prelude" Static="True" />
</ItemGroup>

[micmarsh]

I mostly agree, my primary reason for stealing the namespace was laziness and lack of creativity on my part ("it's a library for x, and uses LanguageExt"). I'm not sure my GitHub handle is a good "brand"/namespace, but I can come up with something better. Locking down the prefix seems like a good move for long-term quality control.

I didn't now about that method of importing things across a whole project; are you able to specify type parameters for generic static classes? The Json library uses "module style" imports exclusively, and I was considering adding that as an option to the HTTP one as well to clean up the per-method type parameters.