Чому б багато динамічних мов програмування типу качок використовували підхід на основі класу замість протоколу OOP на основі прототипу?

23

Оскільки досить багато динамічних мов програмування мають особливості введення качок , і вони також можуть відкривати та змінювати методи класу чи екземпляра в будь-який час (наприклад, Ruby та Python ), то…

Запитання 1) Яка потреба в класі динамічної мови? Чому мова створена таким чином, щоб використовувати клас як якийсь "шаблон", а не робити це по прототипу і просто використовувати об'єкт?

Також JavaScript заснований на прототипі, але CoffeeScript (розширена версія JavaScript) обирає класний спосіб. І так само для Lua (на основі прототипу) та MoonScript (на основі класу). Крім того, є клас у ES 6. Отже…

Запитання 2) Чи передбачає, що якщо ви намагаєтеся вдосконалити мову, засновану на прототипі, серед іншого, ви повинні змінити її на основі класу? Якщо ні, то чому він створений саме так?

— iceX
джерело

9

Багатьом програмістам не хочеться заважати вивчати щось нове. (Це занадто іноземно і "важко"). Звідси всі ті бібліотеки на основі класу та мови, що складаються до них.

— Томас Едінг

1

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

— Lonnie Best

1

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

— амон

3

Перше, що спочатку: сам JavaScript підтримує classключове слово з наступного стандарту ECMAScript (ECMAScript 6). Підтримка занять у JavaScript планувалася давно. Тепер, що це таке - класи - це просто синтаксичний цукор, простіше міркувати про модель для предметів одного типу. Це так у JS, і так в Python та інших динамічних мовах.

— Бенджамін Грюнбаум

1

@BenjaminGruenbaum "... заняття - це просто синтаксичний цукор ..." ух, це начебто досить нова ідея для мене, насправді для таких мов, як рубін і пітон, здається, що не має значення, використовувати об’єкт чи клас як шаблон - обидва можна будь-коли змінювати на льоту. І навіть неважливо, як вони поводяться зі спадщиною. Тож, можливо, не потрібно розрізняти підхід на основі класу та підхід на основі прототипу для динамічної мови :)

— iceX

12

Запитання 1) Яка потреба в класі в динамічній мові? Чому мова створена таким чином, щоб використовувати клас як якийсь "шаблон", а не робити це по прототипу і просто використовувати об'єкт?

Найперша мова ОО (хоч її не називали "ОО"), симула, не мала успадкування. Спадництво було додано в Simula-67, і воно базувалося на класах.

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

Через пару місяців Ден Інгаллс придумав дизайн класів, де самі класи були об'єктами, а саме екземплярами метакласів. Алан Кей виявив цю конструкцію трохи менш привабливою, ніж старіші, тому Smalltalk-74 був розроблений з класами та з успадкуванням на основі класів.

Після Smalltalk-74, Алан Кей відчув, що Smalltalk рухається в неправильному напрямку і насправді не представляє, про що йдеться в OO, і запропонував команді відмовитися від Smalltalk і почати свіжим, але він був переможений. Таким чином, слідували Smalltalk-76, Smalltalk-80 (перша версія Smalltalk була випущена дослідникам), і нарешті Smalltalk-80 V2.0 (перша версія, що випускається комерційно, і версія, яка стала основою для ANSI Smalltalk) .

Оскільки Simula-67 та Smalltalk-80 вважаються бабусями та дідусями з усіх мов ОО, майже всі мови, які слідували за ними, сліпо копіювали дизайн класів та успадкування на основі класів. Через пару років, коли інші ідеї, такі як успадкування на основі міксинів замість класів, та делегування на основі об'єктів замість успадкування на основі класів, що з'явилися на світ, класичне успадкування вже стало занадто закріпленим.

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

— Йорг W Міттаг
джерело

"... сучасна мова Алана Кей ..." яка ...?

— Хав'єр

@Javier: Я не думаю, що це ім'я, і назва системи постійно змінюється.

— Йорг W Міттаг

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

— Ей,

1

@iceX: Алан Кей заснував Науково-дослідний інститут Viewpoints, щоб працювати над його ідеями. На жаль, інформація дійсно розсіяна на веб-сайті.

— Йорг W Міттаг

3

Цитата Алана Кей на ОО: "OOP для мене означає лише обмін повідомленнями, локальне збереження та захист і приховування державного процесу, а також надзвичайну прив'язку всіх речей. Це можна зробити в Smalltalk та LISP. Можливо, є інші системи в що це можливо, але я їх не знаю ".

— Joeri Sebrechts

23

Багато програмістів віддають перевагу роботі з класами. Це дуже легко зрозуміти поняття, яке є хорошою моделлю мисленнєвих процесів людини про світ (тобто ми інстинктивно співвідносимо реальні об'єкти з абстрактною групою предметів, до яких вважаємо, що вони належать, до чого належить клас) . Крім того, класи полегшують міркування про типи об'єктів: у мові на основі класів застосування таких принципів, як заміщення Ліскова , простіше, ніж у мові, де у нас просто є об'єкти, які можуть мати різні методи, або тип яких може навіть змінюватися під час виконання , як у випадку з JavaScript.

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

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

— Жюль
джерело

4

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

— Йорг W Міттаг

4

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

— Жуль

11

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

— Йорг W Міттаг

1

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

— Жуль

1

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

— KChaloux

3

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

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

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

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

— Lonnie Best
джерело

1

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

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

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

— gbjbaanb
джерело