Allow wiring of a theme object without an Enum definition

Trouble is Pinto as it is, is flexible so you can have objects located anywhere. If you look into internals, you’ll find the file name of the class is picked up with reflection. Even outside of regular src/ discovery. It’s not efficient to scan every directory in a project, so this is what we have.

A solution could be to have a rigid, scanned directory/namespace just like Pinto enums do right now.

This is kinda related to https://github.com/dpi/pinto/issues/4, putting all the metadata in the enum. Maybe solves issues with metadata spread all over? So your objects become purely about input/output.

I personally feel like all this information belongs on the theme object and would be totally fine with a constrained namespace (allowing for sub namespaces too) if that would unlock it.

We can support this scenario alongside existing.

Pinto/Objects namespace?

Probably configurable alongside the existing namespace container parameter.

Should a new attribute register a class as an object, or pick up the existing attribute?

I’m sure there are internal design issues that need to be resolved in order to couple from enums, while keeping existing functionality.

I am concerned on how we’d approach dealing with the things enums do for us. It do you imagine an object class magically gets bound to an enum, without an explicit Definition attr, or something?

Should a new attribute register a class as an object, or pick up the existing attribute?

Maybe the ThemeDefinition would be enough?

I am concerned on how we’d approach dealing with the things enums do for us.

You mean the other things like templateDirectory etc?

In the meantime, Enum still remains the backbone to which everything derives. However new features (in 0.2.0) make enum more more important, including allowing the posibility of metadata like #[ThemeDefinition], and the new #[Slots] to be placed on the enum case or enum class itself.

Assets are also a possibility...