[Libre-soc-dev] liskov substitution principle and type assertions/annotations

[Jacob Lifshay]

On Tue, Aug 9, 2022, 21:59 lkcl <luke.leighton at gmail.com> wrote:

> On Wed, Aug 10, 2022 at 5:20 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> >
> > On Fri, Aug 5, 2022, 19:59 lkcl <luke.leighton at gmail.com> wrote:
>
> > 3. type assertions also help IDEs give you the correct information, e.g.
> if it knows some variable v is a str then it can autocomplete str's methods
> -- when you type v.isd it can give you v.isdigit. when you hover over a
> variable, it can tell you it's a str. when you do something like try to
> append it to a list[int] variable, it can tell you that you messed up there
> because str isn't int. This is very beneficial as, in my experience, it can
> speed up writing code by a factor of 2x or more.
>
> i have told you multiple times that you are not to poison the
> HDL with type annotations, and that if you absolutely insist
> on adding them to put them into a separate file which your choice
> of IDE benefits from.
>

I already stated I will remove type *annotations* including dataclasses
from our HDL code, apparently I wasn't at all clear, sorry for the
confusion:
https://libre-soc.org/irclog/%23libre-soc.2022-08-06.log.html#t2022-08-06T04:44:14

>
> yet you continue not only to fail to do that, you continue to repeat
> that "type annotations make things better".
>

I'm not removing them because I no longer think type annotations are
better, i'm removing them because it will make our project run better to
have code lkcl can more easily read.

>
> i have told you multiple times that they make code both unreadable
> and longer both in width and height by unacceptable percentages
> and yet you systematically fail to acknowledge this as being in
> any way important.
>

that because that's important to you whereas I think most type annotations
have a small effect on the size and beneficial effect on understandability.
I'm removing them because you have trouble reading them.

>
> you have made it absolutely clear that you despise python
> but the resentment that you clearly and non-clearly express
> is causing me considerable distress and anger at having to
> constantly fire-fight and watch out for the repeated systematic
> breaking of rules that i have specifically set.
>
> when you can *listen* and respect the rules that i set,


I'm attempting to respect the rules we as a project agree on. we agreed on
no type annotations for hdl, recently changed to remove the exception for
dataclasses.

What we didn't agree on is no type assertions (of the instanceof form) or
other useful assertions, which I'm trying to argue we should still
allow/promote when appropriate.

rather
> than ignore them because of the resentment that you feel
> for being "forced" to work on python "because it is not rust-like",

then i will be more inclined to listen to what you have to say.
>
> please *stop* applying rust programming language concepts
> and constructs to python.


These are not rust concepts, rust intentionally doesn't have traditional
subclassing on which the LSP critically relies.

These are python concepts, and I'm pointing out that both type annotations
and assertions are compatible with LSP, therefore LSP should not be used as
your reason for removing them.

This does not mean I'm arguing we should allow type annotations solely
because LSP allows them, you already gave other reasons for not allowing
them and we agreed to not allow them.

This does mean that the only argument I remember you giving for removing
type assertions is invalid though, so if you want to remove them, please
give me a reason other than "incompatible with LSP".

Once you can produce another argument, then we can decide if removing
assertions is really a good idea or not.

given what I currently know, removing type or other assertions is usually
not beneficial and I think we should revert commit:
https://git.libre-soc.org/?p=nmutil.git;a=commitdiff;h=d72880215d54123709c8c02b86446b5a752c27c9

Jacob