✨Better Code Organization

[WillXuCodes]

Summary:

• ADI classes were given their own adi namespace under pros, and backwards compatibility was added with the old API with a deprecated warning.
• Controller and new devices were added to a v5 namespace (under pros namespace).
• mutex and Task were given their own rtos namespace (also under pros).
• rtos and v5 namespaces are inline so they already have backwards compatibility.

Motivation:

For better organization if we're to move to doxygen for our docs.

References (optional):

#223 #224

Test Plan:

(This code builds properly from my deviceless testing)

• Try initiating different pros v5 devices, motors, and adi sensors/motors to see if they work and scope properly with the new code organization.

[WillXuCodes]

@kunwarsahni01 you mind testing this when u got the time? Thanks.

[kunwarsahni01]

Everything seems to be working here, tested with Controller and IMU.

[Octogonapus]

This is supposed to be fully backward compatible, right? If so, I would appreciate the chance to test it on OkapiLib.

[WillXuCodes]

This is supposed to be fully backward compatible, right? If so, I would appreciate the chance to test it on OkapiLib.

Yes, everything should be backwards compatible. The v5 devices use an inline namespace to do so, and the ADI stuff uses a macro that also prints a deprecated warning if the old api is used.

[edjubuh]

prints a deprecated warning if the old api is used.

When will the old API be removed? Why is the old API being removed? These explanations would be good to give to users when breaking their code

[Octogonapus]

This does not break OkapiLib.

[WillXuCodes]

prints a deprecated warning if the old api is used.

When will the old API be removed? Why is the old API being removed? These explanations would be good to give to users when breaking their code

As for the why, it's to do with us attempting to switch to doxygen for our documentation. This change isn't going to break their code due to the backwards compatibility measures in place, unless you're referring to when we actually remove it down the line.

[edjubuh]

This change isn't going to break their code due to the backwards compatibility measures in place, unless you're referring to when we actually remove it down the line.

If you're putting a warning on their code, it's breaking their code 😃

[HotelCalifornia]

This change isn't going to break their code due to the backwards compatibility measures in place, unless you're referring to when we actually remove it down the line.

If you're putting a warning on their code, it's breaking their code 😃

so this is where the discussion of bumping major versions comes into play. the goal i think is that we'll try to maintain backwards compat (i.e. the code users have works albeit with warnings) for the short term but since it's a major version upgrade there are no guarantees

[edjubuh]

As for the why, it's to do with us attempting to switch to doxygen for our documentation.

I didn't really get the sense that the maintaining backwards compatibility with the current API has a significant impact on improving documentation. I think I'm missing something here.

It's worth mentioning that PROS 2 projects still today should compile in PROS 3. We have a header which #defines all the PROS 2 APIs into PROS 3 functions.

[nickmertin]

so this is where the discussion of bumping major versions comes into play. the goal i think is that we'll try to maintain backwards compat (i.e. the code users have works albeit with warnings) for the short term but since it's a major version upgrade there are no guarantees

It's worth mentioning that PROS 2 projects still today should compile in PROS 3. We have a header which #defines all the PROS 2 APIs into PROS 3 functions.

So perhaps, keep the backwards-compatibility for a PROS 3 release, then break compatibility with PROS 4? Otherwise, we run into the issue of having some things break on 4.0, while others break on 4.1, etc. IMO breaking everything that we plan to break in one release is better because it limits the number of releases in which people have to worry about breaking changes, and in the long run doesn't really affect the compatibility. Thoughts?

[HotelCalifornia]

IMO this discussion has gone a little bit off the rails. the specific purpose of this PR is to better organize PROS classes into logical units. deprecating the old ADI class names is, however disruptive to users' workflow, not a breaking change in my mind. code will still compile, and those who choose to ignore the warnings may do so at their own risk. beyond that, there will be no tangible change to the end-user API, except that some classes may, if the user so chooses, be referred to by more fully-qualified names.

if and when version 4 lands, we can certainly create another "legacy header" for PROS 3 in the same way that one was created for PROS 2. however, that change specifically is out of the scope of this PR.

[HotelCalifornia]

that's why I converted it into a draft PR... no need to close it

[WillXuCodes]

Fixed up this PR after merges with the ext-adi changes, not much other than renaming and fixing up a couple issues with merge conflicts. Needs re-testing before PROS-4 merge.

[WillXuCodes]

Closing since all work for PROS 4 will be done on the develop-pros-4 branch