Чому компілятор Scala не може подати попередження про відповідність шаблону для незапечатаних класів / ознак?

Якщо я використовую ип запечатаний traitабо abstract classв Scala , а потім використовувати пошук по шаблоном, цікаво, це компілятор не знає під час компіляції для цієї конкретної patternmatch , які можливих реалізацій цієї ознаки / класу доступні? Отже, якщо це так, чи не може він подавати попередження відповідності шаблону, навіть якщо trait/ abstract classне запечатано, тому що він знає, які типи можна використовувати, перевіривши всі можливі залежності / імпорт?

Наприклад, якщо у мене є Option[A]і я збігаю шаблони тільки для, Some[A]але не для None, компілятор поскаржиться, оскільки Optionце запечатано.

Якщо компілятор не може це знати / вирішити, то чому він не може? І якщо компілятор (теоретично) може це зробити, то які причини цього не використовуються в Scala? Чи існують інші мови, які підтримують таку поведінку?

Висвітлення всіх підкласів класу називається ієрархічним аналізом класів, а статичне CHA мовою з динамічним завантаженням коду рівнозначно вирішенню проблеми зупинки.

Крім того, одна з цілей Scala - це окрема компіляція та розгортання незалежних модулів, тому компілятор просто не може знати, чи є клас підкласовим в іншому модулі, оскільки він ніколи не переглядає більше одного модуля. (Зрештою, ви можете скласти модуль проти інтерфейсу якогось іншого модуля без того, щоб цей модуль навіть існував у вашій системі!) Тому sealedпотрібно, щоб усі підкласи були визначені в одному блоці компіляції.

Це також одна з причин, чому JVM можуть настільки вигідно конкурувати з компіляторами C ++: компілятори C ++, як правило, є статичними компіляторами, тому вони взагалі не можуть з’ясувати, перевіряється чи ні метод, і, отже, не можуть його вбудувати. JVM OTOH, як правило, є динамічними компіляторами, їм не потрібно виконувати CHA, щоб з'ясувати, чи є метод замінений чи ні, вони можуть просто подивитися на Ієрархію класів під час виконання. І навіть якщо пізніше в процесі виконання програми з'явиться новий підклас, якого раніше не було, нічого великого, просто перекомпілювати цей фрагмент коду без вставки.

Примітка: все це стосується лише Scala. JVM не має поняття sealed, тому цілком можливо підкласи sealedкласів з іншої мови JVM, оскільки немає можливості донести це до іншої мови. sealedВластивість записується в ScalaSigанотації, але компілятори інших мов не брати ці анотацій до уваги, очевидно.

Це можна зробити (принаймні для всіх класів, відомих під час компіляції), це просто дорого. Ви б повністю знищили інкрементальну компіляцію, оскільки все, що містить відповідність шаблону, фактично потрібно було б перекомпілювати щоразу, коли змінювався будь-який інший файл.

А що ви купуєте? Це запах коду для написання відповідностей шаблонів, які потрібно часто змінювати, коли додається новий похідний клас. Це порушення принципу відкритого / закритого типу . Використовуйте спадщину належним чином, і вам не потрібно буде писати такі відповідність шаблонів. І так, принцип відкритого / закритого характеру також стосується функціональних мов без успадкування на основі класів. Насправді між такими функціями, як класи типу, мультиметоди та просто звичайні функції вищого порядку, функціональні мови значно розпростягають розширення без модифікацій.