[I had asked this on the PDN in December, and posted as a document elsewhere on Mesh, so I am posting here as a discussion.]

Obviously, when specializing applications, we do so through higher-level rulesets.

Specializing through *classes* is generally optional -- and typically done for work. I'm trying to find the best practice document which actually explains this.

Some ideas, in order of importance:

1. Concrete classes can be saved in separate tables
2. With transform rules, you can call invoke super() rule for parent classes (doesn't work for rulesets)
3. Rules can inherit via pattern
4. Packaging is Java-like (everything organized)

There's a downside -- it keeps the rules separate in the explorer & smartprompts, which may or may not be desirable -- if most of the rules are in parent classes.

Certainly this is done for work.

Data & Index classes -- sometimes, but not always.

But what about abstract classes like Embed, portals? What about settings?

There's a "workpool" but no "datapool"...

Consider CPM. Looking at v6.2, we see the work class is under PegaCA-, while the portals and settings are under CPM-

Should we subclass the CPM-Portal classes? (or should we explicitly not?)

Suppose we don't specialize... and we want to apply Whens/Privilege test in the portal or navigation menu. If we haven't subclassed, the privileges remain in CPM-Portal, which means that we can't reuse them in our own class structure. Unless we put them in @baseclass... and if you have to do that, then you aren't using class specialization!