Всем у кого всё ещё есть вопросы о нужности этого языка рекомендую пройти по ссылке http://lamp.epfl.ch/~odersky/papers/ и читать.

В этих *научных* публикация описываются различные проблемы, которые невозможно решить в существующих языках, предлагаются решения. Scala - была всего лишь демонстрационных проектом. Просто выросла.

В статьях непосредственно о Scala Мартин всегда начинает со списка заимстований. То есть там так и написано, что взято из Smalltalk, что из Erlang, что из Beta. И что уникально новое.

По моему мнению, Scala это такой же шаг вперёд по сравнению с Java/.Net, каким был C по сравнению с Fortran.

> Не могли бы вы рассказать, как это происходит? Я в самом деле не знаю, мне интересно.

Да полно способов. Типичный пример - библиотека построения GUI Swing. В этой библиотеке view регистрируются у модели и ожидают событий о ее изменении. Если мы используем долгоживущие модели данных и создаем для них короткоживущие виджеты (view) и где-нибудь забываем явно прибить view, то потом он так и останется висеть невидимым объектом, и жрать немало памяти во всяких графических контекстах и пр. Типичная утечка

> Единственный вариант утечки который я словил - было открытие файла находящегося внутри jar через URLClassLoader. Это известный, хотя и редкий косяк и его хотят вылечить в 7-ке.

Ну с classloader'ом вообще можно много что намудрить - достаточно погуглить на тему утечек в PermGen при редеплое приложений.

То есть владение view неявно переходит к модели, и единственный способ очистить память --- уничтожить эту модель?

>> [утечка памяти] еще как возможна, просто механизм возникновения другой - утечка ссылки на объект. Но результат - тот же.

Не могли бы вы рассказать, как это происходит? Я в самом деле не знаю, мне интересно.

создаем глобальную переменную - static List и накачиваем его до бесконечности. Поскольку переменна статик, то может быть доступна без экземпляра, а значит GC ее не может убрать.

> Функции с 20 аргументами противоречат идеалогии Java

да, все мы знаем, что реальный мир и потребности программиста-непервокурсника противоречат идеАлогии Java

причем бывают такие случаи, что параметры нельзя распихать в 2-3 струтурки — то есть можно, но насильно, т.к. эти 2-3 структуры нигде кроме и не будут использоваться — типичный пример это команднострочные утилиты

с «развитием» явы, впрочем, тут появлися (как всегда кривой) воркараунд: объявить класс MyClass с этими 20 членами и писать:

f( new MyClass() {{ argument1=1; argument5=5; argument4=4; }} )

З.Ы. в скале ключевые параметры появились совсем недавно

пример?

2. визитор

1. простой пример нарушения DRY — это плюсовые шаблоны, несводимые к явовским дженерикам, например Z<n> — кольцо вычетов по модулю n, или еще проще массив MyArray<n> длинной n, где n известно во время компиляции

> То есть владение view неявно переходит к модели, и единственный способ очистить память --- уничтожить эту модель?

Ну как-то так. При этом если потерять ссылку на исходный widget, то востановить его из listener'а уже нельзя.

Можно явно грохнуть всех listener'ов у модели, но это не всегда возможно.

>> утечка возможна только там, где программист может получить память и забыть ее вернуть. в языках высокого уровня Java, C# или той же scala утечка ПАМЯТИ невозможна.

Элементарно можно выделять память под, например, записи в хэш-таблице и забывать её возвращать. То что память выделяется неявно не отменит того факта, что она не освободится.

просто невозможно. придется не только сделать хэш-таблицу, но и заволнить ее значениями, иначе память не будет выделена.

PS плюс/минус оптимизация памяти - выделяется несколько больше чем запрошено.

создаем глобальную переменную - static List и накачиваем его до бесконечности.

Это как-то грубо. Да и что мешает очистить этот List руками?

Пример maxcom-а мне кажется более коварным. :-)

> причем бывают такие случаи, что параметры нельзя распихать в 2-3 струтурки — то есть можно, но насильно, т.к. эти 2-3 структуры нигде кроме и не будут использоваться — типичный пример это команднострочные утилиты

Для этого создаем настроечный объект, настраиваем его и передаем в качестве параметра функции. Некоторые делают у таких объектов сеттеры возвращающие this, тогда можно цепочки писать (хотя лично не люблю длиные цепочки)

Получается довольно красиво, уж точно лучше чем приведенный изврат с анонимным классом.

визитор

визитор в классическом виде редко когда нужен, это скорее нарушение дизайна чем полезный паттерн

> И много обычных программ можно проще написать на С, а не на жабе?

а что есть «обычная программа»? в школе вот всякие модельки программировали на С, ничего, справлялись (жаба тогда на школьных компах не заводилась).

>Для этого создаем настроечный объект, настраиваем его и передаем в качестве параметра функции.

Там где надо чего-то много считать это не шибко удобно. А вообще банально три параметра одного и того же типа - уже достаточный юсекейс для именованных аргументов.

> Для этого создаем настроечный объект, настраиваем его и передаем в качестве параметра функции

Как настраиваем? Вызовом конструктора снова с 20 аргументами?

Некоторые делают у таких объектов сеттеры возвращающие this, тогда можно цепочки писать (хотя лично не люблю длиные цепочки)

А если часть (или все) поля этого объекта хочется объявить финальными, чтобы компилятор ловил ошибки присвавания Настроечному Объекту?

>Как настраиваем? Вызовом конструктора снова с 20 аргументами?

Типа так:

main.add( new JIcon( icon ), x( 0 ).y( 1 ).width( 1 ).xspan( 2 ) );

> визитор в классическом виде редко когда нужен, это скорее нарушение дизайна чем полезный паттерн

это такое охренеть нарушение дизайна, что в функциональных языках именно оно (нарушение, а не визитор) считается нормой

рассмотрим допустим AST той же явы; на этом AST можно (и нужно) объявлять кучу разных функций, ведущих себя по-разному в узлах — например, подсчет верхней границы времени выполнения — и эти функции неизвестны во время проектирования иерархии классов AST

что предложит нам идеАлогия явы (вероятно, от слова идеал — она, как и идеал, так же далека от реальности) для этого случая?

>А если часть (или все) поля этого объекта хочется объявить финальными, чтобы компилятор ловил ошибки присвавания Настроечному Объекту?

Ну это естессно костыль:) Можно его сделать на колесиках и будут финальные, но это будет костыль на колесиках:)

> Как настраиваем? Вызовом конструктора снова с 20 аргументами?

Нет, вызывом сеттеров

А если часть (или все) поля этого объекта хочется объявить финальными, чтобы компилятор ловил ошибки присвавания Настроечному Объекту?

Настроечный объект на то и настроечный, что бы у него final небыло. Проверки его валидности делаются уже в месте использования.

Хороший пример такого применений - билдеры, описанные в первой части Effective Java. Там такие объекты передаются статическим фабрикам, чтобы избежать большого количества аргументов у конструкторов

> это такое охренеть нарушение дизайна, что в функциональных языках именно оно (нарушение, а не визитор) считается нормой

В каждом языке свои парадигмы.

> Типа так: main.add( new JIcon( icon ), x( 0 ).y( 1 ).width( 1 ).xspan( 2 ) );

Это шло у макскома (и у меня) 2-м пунктом, именно цепочкой методов, возвращающих this.

> В каждом языке свои парадигмы.

я ожидал такую отмазку

ну так что нам говорит парадигма явы для приведенного мной примера?

(хинт: разработчики выбрали именно визитор, http://download.oracle.com/javase/6/docs/api/javax/lang/model/element/Element... )

> ну так что нам говорит парадигма явы для приведенного мной примера?

не знаю, я такую задачу не решал

хинт: разработчики выбрали

В JDK полно ошибок дизайна, так что его классы не всегда пример хорошего (это не применительно к этой задаче, тут я не разбирался)

> Ну это естессно костыль:) Можно его сделать на колесиках и будут финальные, но это будет костыль на колесиках:)

хорошо, временно допустим, что я согласился с кривизной — наличием *внешней* для функции сущности (классу Настроечного Объекта) цель которого чисто *внутренняя* — передать функции параметры

да, а как не-костыльно сделать, чтобы компилятор ловил ошибки присвавания Настроечному Объекту?

мне нужны настоящие финальные аргументы функции... и джиту тоже это бы не помешало, для искейп-анализа и прочих оптимизаций

> не знаю, я такую задачу не решал

ну вот сначала реши, а только потом объявляй ее *стандартное* ООП решение — визитор — «нарушением дизайна»

>да, а как не-костыльно сделать, чтобы компилятор ловил ошибки присвавания Настроечному Объекту?

Ну - иерархией настроечных объектов по допустимым инвариантам:) Будет страшное количество классов конечно - но зато с финальными переменными:)

Я ж говорю будет костыль с колесами. Квадратными. При чем это не поможет в смысле оптимизаций - а наоборот - породит такое количество лишнего кода....

> хорошо, временно допустим, что я согласился с кривизной — наличием *внешней* для функции сущности

может быть не внешней, а например статическим сабклассом. И вообще в Java нет функций, надо отучаться думать в их терминах.

да, а как не-костыльно сделать, чтобы компилятор ловил ошибки присвавания Настроечному Объекту?

Это не задача компилятора

> мне нужны настоящие финальные аргументы функции... и джиту тоже это бы не помешало

jit'у это не нужно, он и сам сусам

теперь о том, как любой паттерн, в данном случае визитор, это нарушение DRY

в нормальном языке можно было бы написать

@has_visitor class Element { ...... };

и компилятор «под капотом» добавил бы метод accept в класс Element и сгенерил бы новый класс (или интерфейс) ElementVisitor; если же нам нужны другие названия, можно было бы написать

@has_visitor(accept=«myAccept», elementVisitor=«MyElementVisitor») class Element { ...... };

>> да, а как не-костыльно сделать, чтобы компилятор ловил ошибки присвавания Настроечному Объекту?

Это не задача компилятора

ну да, в понимании явы задачи компилятора это совсем не предотвращение ошибок программиста

javax.lang.model это весьма низкоуровневая вещь, нужна для реализации фреймворков. Покажи лучше что-нибудь прикладного уровня

> Ну с classloader'ом вообще можно много что намудрить - достаточно погуглить на тему утечек в PermGen при редеплое приложений.

вот специально пытался понять что же течет в приложении. ниасилил =))) происходит что-то жуткое между JDBC Hibernate & Spring - коннекты открываются и висят. Перенес DataSource на АппСервер - ПермГен забыт в веках )))

> ну да, в понимании явы задачи компилятора это совсем не предотвращение ошибок программиста

Да.

> вот специально пытался понять что же течет в приложении. ниасилил =))) происходит что-то жуткое между JDBC Hibernate & Spring - коннекты открываются и висят. Перенес DataSource на АппСервер - ПермГен забыт в веках )))

Я так и не осилил, хотя у меня datasource живет в аппсервере. Но там еще видимо много взякой ерунды есть. Новый tomcat кое-что из этого научился детектить, и это радует

> Я ж говорю будет костыль с колесами. Квадратными.

я вначале не врубился в то, что ты сказал

что интересно, одерски сделал-таки ключевые параметры совсем недавно, хотя это известная из седой старины фича

>> создаем глобальную переменную - static List и накачиваем его до бесконечности.

Это как-то грубо. Да и что мешает очистить этот List руками?

Пример maxcom-а мне кажется более коварным. :-)

Это был первый аргумент одного из С-ников (довольно грамотного при этом), когда мы с ним начали спорить про утечки памяти. И формально он прав.

List очистить можно, то тогда не получится «утечки». Утечка это же забытые данные.

любопытно а если scala RIPница что тогда?

Ну если денег не жаль то почему бы и нет, Minix, Schema следуйщий грант уйдет KolibriOS.

>> вот специально пытался понять что же течет в приложении. ниасилил =))) происходит что-то жуткое между JDBC Hibernate & Spring - коннекты открываются и висят. Перенес DataSource на АппСервер - ПермГен забыт в веках )))

Я так и не осилил, хотя у меня datasource живет в аппсервере. Но там еще видимо много взякой ерунды есть. Новый tomcat кое-что из этого научился детектить, и это радует

старый много-много ругался на это, но это не косяк Tomcat, а ошибка на стыке разных подсистем.

JBoss хотя внутри и Tomcat живет легко выгружет приложения без PermGen. Просто делает это насильным путем ;))

Или я чего-то не понимаю, или одно из двух

List очистить можно, то тогда не получится «утечки». Утечка это же забытые данные.

Так цимес-то как раз в том, небольшие короткоживующие объекты из примера maxcom-а переходят во владение долгоживущего и накапливаются, попусту вися в памяти. Прямого доступа к ним нет (все ссылки потерлись при выходе из блоков/функций), уничтожить их можно только уничтожением объекта-владельца.

Глобальный список же доступен всегда, ничто не мешает в любой момент пройтись по нему и уничтожить часть объектов. Забытые глобальные переменные --- это уже склероз, язык программирования тут не причем.

> теперь о том, как любой паттерн, в данном случае визитор, это нарушение DRY

в нормальном языке можно было бы написать

@has_visitor class Element { ...... };

и компилятор «под капотом» добавил бы метод accept в класс Element и сгенерил бы новый класс (или интерфейс) ElementVisitor; если же нам нужны другие названия, можно было бы написать

@has_visitor(accept=«myAccept», elementVisitor=«MyElementVisitor») class Element { ...... };

так можно и в java сделать, но для стабильности развития платформы многие паттерны не переносят в компилятор. Ваш пример вполне легко можно сделать внутри своей библиотеки - по аннотациям.

Вот отсутствие first class property напрягает, но увы Sun-кам наступил копец до того, как они асилили сделать FCP.

>> List очистить можно, то тогда не получится «утечки». Утечка это же забытые данные.

Так цимес-то как раз в том, небольшие короткоживующие объекты из примера maxcom-а переходят во владение долгоживущего и накапливаются, попусту вися в памяти. Прямого доступа к ним нет (все ссылки потерлись при выходе из блоков/функций), уничтожить их можно только уничтожением объекта-владельца.

ага, понял - там делаются биндинги к данным. похоже их реализация как раз и является косячтой - провоцирует утечку view.

спишу на то, что не являются десктопным разработчиком на java ;)

PS swing - RIP.

jit'у это не нужно, он и сам сусам

да-да

особенно когда метод f, для которого надо сделать искейп-анализ, по-настроящему виртуален (т.е. не принадлежит финальному классу и т.д.)

for(int i=0; i<n; i++) {
   SomeStruct x=g(i); /// и где разместить его -- на стеке или в куче? 
   a[i].f(x);
}

> Ваш пример вполне легко можно сделать внутри своей библиотеки - по аннотациям.

ну расскажи как (а то вдруг я че-то упустил в яве)

особенно интересно, как добавить метод в класс и сгенерить новый класс

еще при этом обязательно, чтобы все остальное при использовании этих классов тайпчекалось, а не «я загрузил класслоадером класс и поверь, там есть эти методы»

В стеке нельзя, потому что не известно каким побочным эффектом обладет метод - может он его публикует где-нибудь

> ага, понял - там делаются биндинги к данным. похоже их реализация как раз и является косячтой - провоцирует утечку view.

спишу на то, что не являются десктопным разработчиком на java ;)

В Qt, Python и про помощи boost::shared_ptr можно легко добиться того же эффекта. :-)

PS swing - RIP.

Честно говоря, на Java писал году в 2003-м учебный пример, с тех пор вообще ее не трогал.

> javax.lang.model это весьма низкоуровневая вещь, нужна для реализации фреймворков. Покажи лучше что-нибудь прикладного уровня

он совсем не страшный и пересказывать повторно мне не хочется, да и вообще это классика

> В стеке нельзя, потому что не известно каким побочным эффектом обладет метод - может он его публикует где-нибудь

а если было бы четко известно, что х не модифицируется, то публикация его куда-то (например, в некий кэш, доступный даже не только для этого метода, но и для других) могла быть заменена простым копированием *, и ничто не мешало бы держать х на стеке

так что джит в растерянности

__________________________________

* если у нас как обычно сборка мусора, а не подсчет ссылок

В чем оптимизация то тогда заключается?

я уж скоро ошибаться начну, завтра продолжим

> особенно интересно, как добавить метод в класс и сгенерить новый класс

еще при этом обязательно, чтобы все остальное при использовании этих классов тайпчекалось, а не «я загрузил класслоадером класс и поверь, там есть эти методы»

можно, то это уже черная магия - не к лицу ее применять.

все АппСервера, JPA и Hibernate живут через генерацию на ходу доп.классов по прототипу существующих. Ничего технологически сложного, но довольно много геморра. есть библиотеки упрощающие byte-code manupulation.

>все АппСервера, JPA и Hibernate живут через генерацию на ходу доп.классов по прототипу существующих

С _расширением_ интерфейсов дополнительными методами, вы, таки, уверенны?