We already have a few classes in Pods (prior to 2.0):

• PodInit()
• Pod()
• PodAPI()
• PodCache()

2.0 will be adding a few more and here’s what the lineup will look like (with the renames, but remember there’s backwards compatibility built into the old names!):

• PodsInit()
• Pods() – best-practice function to init is $var = pods($podname,$id_or_slug)
• PodsUI() – best-practice function to init is $var = pods_ui($ui)
• PodsAdminUI() – best-practice function to init is $var = pods_admin_ui()
• PodsFormUI() – best-practice function to init is $var = pods_form_ui()
• PodsAPI() – best-practice function to init is $var = pods_api()
• PodsMigrate() – best-practice function to init is $var = pods_migrate()
• PodsMigrateUI() – best-practice function to init is $var = pods_migrate_ui()

I’ve purposely excluded PodCache() as we really need to be utilizing the built-in WP object / db caching instead. It may be the case that PodCache() becomes a wrapper for the WP object / db caching, that covers certain functions that may be used / reused substantially throughout Pods.

Also, new classes will be initiated through global functions that include the class code only when needed (instead of loading it up on every page load regardless) pods_classname(), for example – pods_ui(), pods_admin_ui(), etc. – with backwards-compatibility in place for when you use the real class name and the code hasn’t been included yet.