Яку функціональність дозволяє динамічне введення тексту? [зачинено]

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

Окрім нефункціональних критеріїв, таких як гнучкість та читаність, які причини існують для вибору динамічного введення тексту? Що я можу зробити з динамічним введенням тексту, яке інакше неможливо? Який конкретний приклад коду ви можете уявити, що ілюструє конкретну перевагу динамічного набору тексту?

Оскільки ви попросили конкретного прикладу, я наведу вам один.

Масивна ORM Роб Конери - 400 рядків коду. Це так мало, тому що Роб вміє відображати таблиці SQL і надавати результати об’єктів, не вимагаючи багато статичних типів для відображення таблиць SQL. Це досягається за допомогою dynamicтипу даних у C #. Веб-сторінка Роба детально описує цей процес, але видається зрозумілим, що в даному конкретному випадку використання динамічного набору тексту значною мірою відповідає за стислість коду.

Порівняйте з Dapper Сема Шафрона , який використовує статичні типи; SQLMapperв поодинці клас 3000 рядків коду.

Зверніть увагу, що застосовуються звичайні відмови від відповідальності, і пробіг може змінюватися; Дапер має інші цілі, ніж Massive. Я просто зазначу це як приклад того, що ви можете зробити в 400 рядках коду, що, ймовірно, не було б можливим без динамічного набору тексту.

Динамічне введення тексту дозволяє відкласти рішення типу на час виконання. Це все.

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

Прихильники мов статичного типу зазначають, що компілятор може зробити значну кількість "перевірки правильності" вашого коду під час компіляції, перш ніж виконати один рядок. Це хороша річ ™.

C # має dynamicключове слово, яке дозволяє відкласти рішення типу на час виконання, не втрачаючи переваг безпеки статичного типу в решті коду. Виведення типу ( var) усуває значну частину болю при написанні мовою статичного типу, усуваючи необхідність завжди чітко оголошувати типи.

Динамічні мови, схоже, віддають перевагу більш інтерактивному, негайному підходу до програмування. Ніхто не очікує, що вам доведеться написати клас і пройти цикл компіляції, щоб набрати трохи коду Lisp і переглянути його виконання. І все-таки саме те, що я очікую зробити в C #.

Фрази на зразок "статичне введення" та "динамічне введення тексту" дуже багато, і люди, як правило, використовують тонко різні визначення, тож почнемо з роз'яснення, що ми маємо на увазі.

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

Але більшість систем статичного типу не ведуть себе таким чином. Є дві загальні властивості систем статичного типу, які можуть накладати обмеження:

Компілятор може відхилити програму, яка містить помилку статичного типу.

Це обмеження, оскільки багато безпечних програм типу обов'язково містять помилку статичного типу.

Наприклад, у мене є сценарій Python, який потрібно запускати як Python 2, так і Python 3. Деякі функції змінили свої типи параметрів між Python 2 і 3, тому у мене є такий код:

if sys.version_info[0] == 2:
    wfile.write(txt)
else:
    wfile.write(bytes(txt, 'utf-8'))

Перевірка статичного типу Python 2 відхилить код Python 3 (і навпаки), хоча він ніколи не буде виконуватися. Моя безпечна програма містить помилку статичного типу.

В якості іншого прикладу розглянемо програму Mac, яка хоче працювати на OS X 10.6, але скористатися новими можливостями в 10.7. Методи 10.7 можуть або не існують під час виконання, і саме на мене, програміста, їх можна виявити. Перевірка статичного типу змушена або відхилити мою програму для забезпечення безпеки типу, або прийняти програму разом з можливістю створення помилки типу (функція відсутня) під час виконання.

Статична перевірка типу передбачає, що середовище виконання адекватно описано інформацією про час компіляції. Але прогнозувати майбутнє небезпечно!

Ось ще одне обмеження:

Компілятор може генерувати код, який передбачає, що тип виконання - це статичний тип.

Якщо припустити, що статичні типи є "правильними", то існує багато можливостей для оптимізації, але ці оптимізації можуть бути обмежуючими. Хороший приклад - проксі-об'єкти, наприклад, видалення. Скажімо, ви хочете мати локальний проксі-об'єкт, який пересилає виклики методу до реального об'єкта в іншому процесі. Було б добре, якби проксі був загальним (таким чином він може маскуватися як будь-який об’єкт) і прозорим (так що існуючий код не повинен знати, що він говорить з проксі). Але для цього компілятор не може генерувати код, який передбачає, що статичні типи є правильними, наприклад, за допомогою статично вбудованих викликів методу, оскільки це не вдасться, якщо об'єкт насправді є проксі.

Приклади такого видалення в дії включають NSXPCConnection ObjC або TransparentProxy C # (реалізація яких вимагала декількох песимізацій під час виконання - дивіться тут для обговорення).

Коли кодеген не залежить від статичних типів, і у вас є такі засоби, як пересилання повідомлень, ви можете робити багато цікавих речей з проксі-об'єктами, налагодження тощо.

Отже, це вибірки деяких речей, які ви можете зробити, якщо від вас не вимагається перевірити тип перевірки. Обмеження не накладаються статичними типами, а примусовою перевіркою статичного типу.

Змінні, набрані качками, - це перше, про що думають, але в більшості випадків ви можете отримати однакові переваги за допомогою статичного виводу.

Але введення качок у динамічно створені колекції важко досягти будь-яким іншим способом:

>>> d = JSON.parse(foo)
>>> d['bar'][3]
12
>>> d['baz']['qux']
'quux'

Отже, який тип JSON.parseповертається? Словник масивів цілих чисел-або-словників-рядків? Ні, навіть це не досить загально.

JSON.parseмає повернути якесь "значення значення", яке може бути нульовим, bool, float, string, масивом будь-якого з цих типів рекурсивно або словником з рядка до будь-якого з цих типів рекурсивно. Основні переваги динамічного набору тексту полягають у наявності таких варіантів.

Поки що це є перевагою динамічних типів , а не динамічно набраних мов. Гідна статична мова може ідеально імітувати будь-який подібний тип. (І навіть "погані" мови часто можуть імітувати їх, порушуючи безпеку типу під кришкою та / або вимагаючи незграбного синтаксису доступу.)

Перевага мов, що динамічно набираються, полягає в тому, що такі типи не можуть бути встановлені системами статичного виводу. Тип потрібно чітко записати. Але у багатьох таких випадках - включаючи цей раз - код для опису типу є настільки ж складним, як і код для розбору / побудови об'єктів, не описуючи тип, так що все одно не обов'язково є перевагою.

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

Я зроблю приклад. Припустимо, ви реалізуєте просту модель даних для опису об'єктів даних, їх колекцій тощо, яка статично набрана в тому сенсі, що, якщо модель говорить, що атрибут xоб'єкта типу Foo має ціле число, він завжди повинен містити ціле число. Оскільки це конструкція виконання, ви не можете вводити його статично. Припустимо, ви зберігаєте дані, описані у файлах YAML. Ви створюєте хеш-карту (щоб потім бути переданою бібліотеці YAML), отримуєте xатрибут, зберігаєте його на карті, отримуєте інший атрибут, який просто так буває рядок, ... затримаєте секунду? Який тип the_map[some_key]зараз? Добре стріляйте, ми знаємо, що some_keyце є, 'x'а результат, таким чином, повинен бути цілим числом, але система типу навіть не може почати міркувати про це.

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

Звичайно, сьогоднішнє рішення - боксувати все, а потім робити кастинг (або мати купу перекритих методів, більшість з яких піднімають винятки "не реалізовані"). Але це не статично набрано, це хак навколо системи типів, щоб робити перевірки типу під час виконання.

З динамічним набором тексту нічого не можна зробити, чого не можна зробити зі статичним набором тексту, оскільки ви можете реалізувати динамічне введення тексту на вершині мови, яка вводиться статично.

Короткий приклад у Haskell:

data Data = DString String | DInt Int | DDouble Double

-- defining a '+' operator here, with explicit promotion behavior
DString a + DString b = DString (a ++ b)
DString a + DInt b = DString (a ++ show b)
DString a + DDouble b = DString (a ++ show b)
DInt a + DString b = DString (show a ++ b)
DInt a + DInt b = DInt (a + b)
DInt a + DDouble b = DDouble (fromIntegral a + b)
DDouble a + DString b = DString (show a ++ b)
DDouble a + DInt b = DDouble (a + fromIntegral b)
DDouble a + DDouble b = DDouble (a + b)

У достатній кількості випадків ви можете реалізувати будь-яку задану систему динамічного типу.

І навпаки, ви також можете перевести будь-яку статично набрану програму в еквівалентну динамічну програму. Звичайно, ви втратите всі запевнення часу компіляції у правильності, які надає статично набрана мова.

Редагувати: Я хотів зберегти це просто, але ось детальніше про модель об'єкта

Функція приймає список даних як аргументи і виконує обчислення з побічними ефектами в ImplMonad і повертає дані.

type Function = [Data] -> ImplMonad Data

DMember це або значення члена, або функція.

data DMember = DMemValue Data | DMemFunction Function

Розширити, Dataщоб включити Об'єкти та функції. Об'єктами є списки названих членів.

data Data = .... | DObject [(String, DMember)] | DFunction Function

Цих статичних типів достатньо для реалізації кожної динамічно типізованої об'єктної системи, з якою я знайомий.

Мембрани :

Мембрана - це обгортка навколо всього графіка об'єкта, на відміну від обгортки лише для одного об’єкта. Зазвичай творець мембрани починає загортати в мембрану лише один предмет. Ключова ідея полягає в тому, що будь-яка посилання на об'єкт, що перетинає мембрану, сама транзитивно загортається в ту ж мембрану.

Кожен тип обгортається типом, який має той самий інтерфейс, але який перехоплює повідомлення, перегортає та розкручує значення, коли вони перетинають мембрану. Який тип функції обтікання улюбленою статично введеною мовою? Можливо, у Haskell є тип для цих функцій, але більшість статично набраних мов не використовують або вони в кінцевому підсумку використовують Object → Object, фактично відмовляючись від своєї відповідальності як перевіряючих типів.

Як хтось згадував, теоретично не можна багато чого зробити з динамічним набором тексту, якого ти не міг би зробити зі статичним набором тексту, якщо ти самостійно реалізуєш певні механізми. Більшість мов надають механізми релаксації типів для підтримки гнучкості типу, таких як пусті покажчики, і тип кореневого об’єкта або порожній інтерфейс.

Питання в тому, чому динамічне введення тексту підходить і підходить у певних ситуаціях та проблемах.

Спочатку давайте визначимось

Суб'єкт - мені потрібно загальне поняття про якусь сутність у коді. Це може бути все, від примітивного числа до складних даних.

Поведінка - скажімо, у нашої сутності є певний стан і набір методів, які дозволяють навколишньому світу навчити суб'єкта певних реакцій. Дозволяє називати стан + інтерфейс цього об'єкта його поведінкою. Одне об'єднання може мати більше, ніж одна поведінка, певним чином поєднана засобами мови, що надаються.

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

Це, мабуть, щось, що не таке незнайоме. І як ви сказали, ви зрозуміли різницю, але все ж. Напевно, не повне і найточніше пояснення, але я сподіваюся, що веселощі достатньо, щоб принести певну цінність :)

Статичне введення тексту - поведінка всіх об'єктів у вашій програмі вивчається за час компіляції, перш ніж почати запуск коду. Це означає, що якщо ви хочете, наприклад, у вашої сутності типу Person мати поведінку (поводитись, як) Magician, то вам доведеться визначити сутність MagicianPerson і надати їй поведінку фокусника на зразок castMagic (). Якщо ви в своєму коді, помилково скажіть звичайному компілятору Person.throwMagic ()"Error >>> hell, this Person has no this behavior, dunno throwing magics, no run!".

Динамічне введення тексту - в умовах динамічного набору тексту поведінка сутностей не перевіряється, поки ви дійсно не спробуєте зробити щось із певною сутністю. Запуск коду Ruby, який запитує Person.throwMagic (), не буде спійманий, поки ваш код дійсно не надійде. Це звучить неприємно, чи не так? Але це також звучить викривально. На основі цієї властивості ви можете робити цікаві речі. Скажімо, скажімо, ви розробляєте гру, де все може звернутися до Magician, і ви насправді не знаєте, хто це буде, поки ви не дійдете до певного коду. І тоді приходить Жаба, і ти кажешHeyYouConcreteInstanceOfFrog.include Magicі відтоді ця Жаба стає однією конкретною Жабою, яка має Магічні сили. Інші Жаби, ще ні. Розумієте, в мовах статичного введення вам доведеться визначити це відношення за допомогою якогось стандартного середнього значення комбінації поведінки (наприклад, реалізація інтерфейсу). У динамічній мові набору тексту ви можете це робити під час виконання і нікому не буде байдуже.

Більшість мов динамічного набору тексту мають механізми, що забезпечують загальну поведінку, яка вловлює будь-яке повідомлення, яке передається їх інтерфейсу. Наприклад, Ruby method_missingі PHP, __callякщо я добре пам'ятаю. Це означає, що ви можете робити будь-які цікаві речі під час виконання програми та приймати рішення типу, виходячи з поточного стану програми. Це дає інструменти для моделювання проблеми, які є набагато більш гнучкими, ніж, скажімо, консервативна статична мова програмування, як Java.