Skip to content

Limitations of QBase and QEnum #8

@gpetretto

Description

@gpetretto

The QBase and QEnum classes have been introduced to avoid having MSONable classes, if the clien application doesn't want it to be that way. This has apparently been recognised as a limiting factor for adoption of MSONable objects by other projects.

Hower this choice has some negative consequences on the qtoolkit implementation. This issue is meant for discussion of how the optional MSONable inheritance is implemented and for the problems related to it.

Currently known issues:

  • it is not possible to depend on monty for other functionalities, as this would make QBase MSONable.
  • mypy does not support dynamic subclasses and this requires to adding a number of type: ignore in the code to avoid mypy errors.

Potential solutions for some of these issues and their related dowsides:

  • do not rely on the presence of monty for deciding if the base class should be MSONable, but rather on some configuration variable. Not very practical.
  • just implement the as_dict and from_dict methods in QBase. Monty does some duck typing in (de)serializing, so most of the Monty related features would still work. This does not solves security concerns for automatic serialization.
  • Drop the requirement for the objects to be MSONable and just allow some serialization of the objects if needed.
  • Make the objects MSONable and drop QBase and QEnum

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions