Suggestion: Change BaseStyle from class to decorator

[saroad2]

Hi,
So I was wondering why the Pack class in toga does not auto-complete it's properties such as height, width, font_size, background_color, etc.
I found out the reason is the implementation of validated_property makes it impossible for the IDE to recognize the parameters.

Taking inspiration from python 3.7 dataclass, I think that we should make BaseStyle to be a decorator. Here's an example of how the Pack class should look like:

@style
class Pack:

   display = validated_property(choices=DISPLAY_CHOICES, initial=PACK)
   visibility = validated_property(choices=VISIBILITY_CHOICES, initial=VISIBLE)
   direction = validated_property(choices=DIRECTION_CHOICES, initial=ROW)
   alignment = validated_property(choices=ALIGNMENT_CHOICES)

   ...

In that way, we'll get the same functionality + modernized code + auto-completion.

The style decorator will also add the __init__ function and all the other methods which are currently inherited from BaseStyle.

What do you think about this idea?
Once you approve, I'll implement it.

[saroad2]

@freakboy3742 , your input on this matter would be much appreciated :)

I can implement the @style decorator and validated_property as an addition to the existing BaseStyle class, for backward compatibility reasons, and once you approve the new concept I'll use it in the Pack class.

The way Pack doesn't auto-complete it's properties really bugs me.

[freakboy3742]

Sorry for the delay in responding - this fell off the bottom of my todo list.

I'm +1 on the general principle of making Travertino (and downstream related projects) play nice with autocomplete tools (and I can see how the current implementation is completely opaque in this regard). The devil will be in the details.

The prospect of a "declarative" syntax is definitely interesting, though. I guess the follow-on question becomes whether it's done at the level of assignment to a class property as you describe, or using dataclass-style type declarations; e.g.,

@style
class Pack:
    display: validated_property(choices=DISPLAY_CHOICES, initial=PACK)
    visibility: validated_property(choices=VISIBILITY_CHOICES, initial=VISIBLE)
    direction: validated_property(choices=DIRECTION_CHOICES, initial=ROW)
    alignment: validated_property(choices=ALIGNMENT_CHOICES)

I'm mostly throwing that out there as a "possible spelling", not a specific preference for an API style; ultimately, it will be the features (and complexities) of the actual implementation that matter.

[saroad2]

We are actually speaking about the same thing :)
what dataclass does is that it uses the : syntax to define the type of the attribute and = to define its behavior. for example:

@dataclass
class A:
   string_attr: str
   uninitialized_string_attr: str = field(init=False)
   unrepresented_string_attr: str = field(repr=False)

In our case we'll do it in the following way:

@style
class Pack:
    display: str = validated_property(choices=DISPLAY_CHOICES, initial=PACK)
    visibility: str = validated_property(choices=VISIBILITY_CHOICES, initial=VISIBLE)
    direction: str = validated_property(choices=DIRECTION_CHOICES, initial=ROW)
    alignment: str = validated_property(choices=ALIGNMENT_CHOICES)

    padding_top: int = validated_property(choices=PADDING_CHOICES, initial=0)
    padding_right: int = validated_property(choices=PADDING_CHOICES, initial=0)
    padding_bottom: int = validated_property(choices=PADDING_CHOICES, initial=0)
    padding_left: int = validated_property(choices=PADDING_CHOICES, initial=0)

in that way, we are indicating to the IDE that the padding attributes are integers and that the other attributes are strings.

What do you think?

[freakboy3742]

Ah - I was reading your example as being more akin to Django model declarations (which I imagine could also be turned into a completely workable design). However, the added type info in addition behavioral config sounds like a good addition. Getting the types right will be a challenge for more complex examples (e.g., in Colosseum, padding is a value with a unit) - but I'm pretty sure that's an implementation detail of type declaration, rather than a problem with this as a design.

At this point, I guess its "show me the code" :-)