Followup: modularity, WebExtensions, and going faster

[David Teller]

On 12/10/16 15:33, Gijs Kruitbosch wrote:
> On 12/10/2016 14:01, David Teller wrote:
>> 2/ if we have poor modules, static checking is mostly going to confirm
>> that we have poor modules, but if we have better modules, static
>> checking is going to be more useful.
> This doesn't make a lot of sense to me. The annotations are, I assume,
> for globals as well as function/method signatures. Why would it matter
> how we organize modules?
> (Which isn't to say that we shouldn't pay attention to modular code, but
> it doesn't seem like it'll impact static type checking.)

Let's call it a hunch (based on my experience of static checking,
including static typing). I'm, of course, willing to be favorably surprised.

>> I agree that static type-checking is mostly orthogonal with the choice
>> of a way of modularizing the code (regardless of whether this "way" is a
>> specific technology, a set of review guidelines or anything inbetween).
>> On the other hand, I strongly believe that supporting strong typing
>> (note that I didn't write "static typing") at API boundaries is
>> important.
> Right now there are no API boundaries at all in the strict sense of the
> word, or alternatively, any JS global or function/method is an API
> boundary.

Indeed. As I understand this thread, this is exactly the essence of the
problem we're discussing.

> I'm also not sure why, even for "properly structured modules" of
> whatever kind, we wouldn't care about types used internally, and only
> about the API boundaries...

We certainly do. If I wrote something that lead you to believe that we
don't, I apologize for the lack of clarity.

Cheers,
 David