Classes misrepresented in Utility

[reaperdtme]

Utility does a lot to make life easier, but classes have been misrepresented. Classes should be treated the same way javascript does, ie, as Objects. Class keys and values are treated in the Object hasOwnProperty fashion.

• $Shape on a class should ignore prototype methods/properties, the same way Object prototypes are ignored.
• $Diff should again treat classes as objects.

These two are extremely useful for Class constructors, ie, accepting $Shape as parameter, or $Diff<this, DefaultProps>

Other places support is needed:

• $ObjMap(i) should map hasOwnProperty keys/values of class
• ... should spread hasOwnProperty keys/values of class

The output type of these functions when applied to class are expected to be Objects.

Per impl, someClassInstance instanceof Object === true

Some reasoning:

• Object.assign({}, myClassInstance) behaves as expected. Assigning only hasOwnProperty key:value types (not prototype methods/properties). The same should go for utility methods.
• The use case for these are obviously in Object-> Class and Class -> Object flows, creation/serialization
• All classes inherit Object, ie, have Object.prototype methods of hasOwnProperty, toString... etc

[nmn]

While you're probably right about everything, the Utility types are experimental at best and there are many other problems with them that will need to be fixed way before the case for classes will be looked at.