Аннотация:
Язык Scala был создан в 2001-2004 гг в лаборатории методов программирования EPFL. Он стал результатом исследований, направленных на разработку более хорошей языковой поддержки компонентного ПО. С помощью Scala мы хотели бы проверить две гипотезы. Во-первых, мы считаем, что язык программирования компонентного ПО должен быть масштабируемым в том смысле, что должна быть возможность с помощью одних и тех же концепций описать как маленькие, так и большие части. Поэтому мы сконцентрировались на механизмах абстракции, композиции и декомпозиции вместо введения большого количества примитивов, которые могут быть полезными только на каком-то одном уровне масштабирования. Во-вторых, мы считаем, что масштабируемая поддержка компонентов может быть предоставлена языком программирования, унифицирующим и обобщающим объектно-ориентированное и функциональное программирование.
09.08.07 15:33: Перенесено модератором из 'Философия программирования' — Odi$$ey
Пример с trait-ом Bool и объектами False и True. В описании аргумента методов нет пробела между ключевым словом def и именем x:
def &&(defx: Bool) : Bool;
а нужно
def &&(def x: Bool) : Bool;
Я пока допер что defx -- это два разных слова, чуть не свихнулся в попытках понять, как Scala догадывается, что идентифкатор defx указывает на необходимость своего ленивого вычисления
Не переведенная фраза в тексте.
Вот две реализации класса GenList:
Here are two implementations of the GenList class:
Если каждая операция в Scala – это вызов метода, то как насчет разыменования и присваивания переменных? На самом деле, при работе с членами классов эти операции также расцениваются как вызовы методов. Для каждого определения переменной varx:T в классе Scala определяет методы setter и getter:
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Зря вы так.
Матеиал очень интересный. Хотя бы что касается
"масштабируемая поддержка компонентов может быть предоставлена языком программирования, унифицирующим и обобщающим объектно-ориентированное и функциональное программирование". Скажем, определение функций, параметрических относительно различных типов; проблема внешней расширяемости и т.д. Многие концепции заставляют очень серьезно задуматься...
С помощью Scala мы хотели бы проверить две гипотезы. Во-первых, мы считаем, что язык программирования компонентного ПО должен быть масштабируемым в том смысле, что должна быть возможность с помощью одних и тех же концепций описать как маленькие, так и большие части.
Если за 30 лет с того времени, как было сказано, что система должна состоять из равноправных кусочков (объектов) на микро и макро уровне, этого никто не доказал, то и мужиков врядли что получится
С помощью Scala мы хотели бы проверить две гипотезы. Во-первых, мы считаем, что язык программирования компонентного ПО должен быть масштабируемым в том смысле, что должна быть возможность с помощью одних и тех же концепций описать как маленькие, так и большие части.
> > Если за 30 лет с того времени, как было сказано, что система должна состоять из равноправных кусочков (объектов) на микро и макро уровне, этого никто не доказал, то и мужиков врядли что получится
Дальше в том же духе:
Scala uses a pure object-oriented model similar to
Smalltalk’s: Every value is an object and every operation
is a message send.
Another aspect of Scala’s unified object model is that every
operation is a message send, that is, the invocation of
a method. For instance the addition x + y is interpreted as
x.+(y), i.e. the invocation of the method + with x as the
receiver object and y as the method argument. This idea,
which has been applied originally in Smalltalk, is adapted
to the more conventional syntax of Scala as follows.
From Smalltalk [17] comes the concept of a uniform
object model.
Здравствуйте, Максс, Вы писали:
М>Зря вы так. М>Матеиал очень интересный. Хотя бы что касается М>"масштабируемая поддержка компонентов может быть предоставлена языком программирования, унифицирующим и обобщающим объектно-ориентированное и функциональное программирование". Скажем, определение функций, параметрических относительно различных типов; проблема внешней расширяемости и т.д. Многие концепции заставляют очень серьезно задуматься...
Вообще, роль языка как-то четко не вырисовывается. Они попытались различные идеи собрать в одном месте, да и еще сверху платформ, вполне самодостаточных со своими идеями.
На уровне имплементации и переносимости меня убил пример с разницей семантики Substring(int, int) и substring(int, int). Понятно желание дать возможность писать переносимый код, но для этого нужно было как-то зафиксировать семантику для примитивных типов хотя бы (даже если они и выполнены как реализации классов в .Net и Java). Т.е. жесткая последовательность в таких вопросах всяко лучше, чем приведенный пример незаметных и подлых граблей.
В плане миксинов +1. И ограничения на миксины и их реализация — все логично, я бы на месте Java и .Net разработчиков этих платформ присмотрелся бы.
Насчет остального... Немного юморно выглядят попытки расширять ограниченные ОО-языки встроенными спец-конструкциями, которые в том же С++ легко выражаются с помощью базовых (и можно выразить еще теоретически бесконечное множество паттернов и конструкций). Может, стоит получше прорабатывать базовые конструкции языка?
>Мы отказались от этого, поскольку хотели сохранить как инвариант то, что интерпретация значения подкласса как экземпляра его суперкласса не меняет представления значения.
Неужто это нельзя было как-то перевести на литературный русский/английский язык или хотя-бы на программерский жаргон?
Здравствуйте, AlexTarvo, Вы писали:
>>Мы отказались от этого, поскольку хотели сохранить как инвариант то, что интерпретация значения подкласса как экземпляра его суперкласса не меняет представления значения.
AT>Неужто это нельзя было как-то перевести на литературный русский/английский язык или хотя-бы на программерский жаргон?
Попробуй. Получится лучше — заменим.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
