patible with
the existing property system we have in `2.x`. Unless we offer something
better, I don't see a reason why we shouldn't simply reuse it.
On Thu, Jan 4, 2024 at 10:13 AM Piotr P. Karwasz
wrote:
> Hi all,
>
> Looking at the `PropertyKey` abstraction in `3.x`, I was wonderi
FWIW, I'm NOT a fan of the static analysis option. Good design should be
reflected in the code. We should not pick suboptimal abstractions (or no
abstraction in this case) plus static analysis to validate odd design
choices.
Gafy
On Thu, Jan 4, 2024, 11:29 AM Piotr P. Karwasz
wrote:
> Hi Ralph,
Hi Ralph,
On Thu, 4 Jan 2024 at 16:20, Ralph Goers wrote:
>
> PropertyKey was created so that all “components” could be specified as an
> enum value, thus ensuring consistency.
>
> The split between component and key is used in every declaration of a
> property.
>
> It is unfortunate that the k
t 2:13 AM, Piotr P. Karwasz wrote:
>
> Hi all,
>
> Looking at the `PropertyKey` abstraction in `3.x`, I was wondering
> what advantages it brings over simple string constants. From my
> perspective it has more cons than pros.
>
> Pros:
>
> * it is typesafe; a committer
Hi all,
Looking at the `PropertyKey` abstraction in `3.x`, I was wondering
what advantages it brings over simple string constants. From my
perspective it has more cons than pros.
Pros:
* it is typesafe; a committer must create an instance of it to use it;
Cons:
* it is hard to list for
