Systems are not isolated from the rest of the project about open-project-1 HOT 4 CLOSED

It's easier to manage the Systems like that - think of them as a Packages.
And it's not about compilation time benefit, it's for good project organisation and reusability.

Here's some current problems I've encountered:

• When coding, IDE shows me all the project scripts that has nothing to do with the system I'm working on, and I can accidentally add some unwanted dependency just from auto namespace import..

• I want to make internal classes specifically for Audio, but I can't, as internals are visible across Player / Editor assemblies.

• If I would copycat Audio folder into other project, it would give me tons of mysterious error messages and I'll need to search for so many missing scripts that are scattered all around the source project..
  With asmdef I would know exactly which dependency references I need, and I'll just add Factory and Pool to fix it.

I'll make a PR then, just worried it would conflict with others.

from open-project-1.

we don't want to accidentally create dependencies hell.

Dependencies happen whether or not .asmdef are there. So they are not a cure.

Factory and Pool don't need to be in the same assembly, as @davejrodriguez pointed out in his PR for documentation #189, they are two tools and the Factory could be used independently.

I have removed the stray ReorderableList script, but other than that I am not 100% sure filling the project with .asmdefs is the way to go. If you fancy reorganising things though, make a PR for it! But isn't it harder to handle scripts after that? Compilation times are not high, so I don't see much use for .asmdef-fing the whole project.

Also, we prefer to keep UOP1 as a prefix rather than ChopChop.

from open-project-1.

Should I close this issue?

from open-project-1.

Welp, it only got worse overtime.

from open-project-1.