Philosophy: should LitJson package be tied to Unity?

[BBI-YggyKing]

Should we make this package tightly coupled to and dependent on Unity, or make Unity integration an optional module?

Is our top priority to make this the Json package for Unity users? Or do we want to continue to support non-Unity users that want a lightweight Json package?

Does Unity integration need to be tightly embedded or can it be isolated to a folder in the root of the package and integrated at build time for those who want it?

Or should Unity integration be a whole separate package, which includes a nested version of LitJson?

[BBI-YggyKing]

I think this can and should be the LitJson package, so I would lean towards doing the Unity integration as a separate repository (with LitJson as a git submodule?), or at least isolate all Unity dependencies to a separate source folder, and enable the Unity integration to be built into a separate DLL from the core package.

[Mervill]

The original idea of this fork was to provide a landing page for the search phrase unity3d json library. Once of the tasks I've had to repeat most often is writing the float / Vector3 importer/exporter scripts each time I pulled LitJSON. It's nice to not have to do that anymore.

There's also the matter of platform compatibility, at the moment this relates specificity to WinRT, but I suspect there are bugs in the lib on other platforms that will be addressed in the future. This is why it's important that the Unity version be in the uncompiled format, it allows the Unity compiler to manage which patch gets used when the project is built.

If the will exists to turn this into the LitJson repository, I'm totally on board. Some of the new features and issues are a tad out of my depth, but I'll help where I can and I can be responsible for maintaining Unity compatibility.

I mentioned in another pull request that all we really need to do in order to 'support' Unity alongside a more generic library is to provide a .unitypackage of the uncompiled source, updated every major release. That combined with proper use of processor directives should make targeting either situation a breeze.

Oh, Minor note. One of my commits removed the CLSCompliant attribute from the project, this means the lib will broken if you try to access it in a CLR language that's not C#. It's a easy thing to add back, but we'll have to wrap the attribute in STANDALONE_DLL or whatever we decided that directive should be.

[BBI-YggyKing]

That all makes sense. Couple specific observations ...

• we should make WinRT support independent of Unity, since it's not (just) a Unity issue
• Unity package with uncompiled source certainly sounds simplest, and would streamline the release process (no need to build and bundle different versions, or come up with any scheme for dynamic DLL selection Unity (wish Unity had that built-in ...))
• the CLSCompliant attribute could be #if USE_CLSCOMPLIANTATTRIBUTE -- which isn't present in the Unity environment, so it will do what you want, and can be added to the build process for platforms that need it (via makefile, VS project, etc.).
• in general it's better to #if the feature by a reference to the feature itself, rather than a platform, it makes the code clearer and lets you gather config information in one place for each platform

[Mervill]

Good call about the directive. One of the more frustrating things about open source code is that there never seems to be a list of directives and what they do... "This has been left as an exercise for the reader" or so they say.

[BBI-YggyKing]

We had that sort of problem years ago on FIFA. Instead of "#if USE_GAMEPAD" you'd see "#if XBOX || PS2 || N64 || ..." -- nightmare! We eventually cleaned up and it was way better.