R>Конкретнее можно? Про исходный код... к примеру, SWT/JFace так попросту напичкан всевозможными NullPointerException, IllegalArgumentException и etc.
SWT — отдельный разговор. Я в него не играю с тех пор, как пересел дома на MSVUx64, потому что нет нормальной реализации.
>В особенности интересна претензия к архитектуре Eclipse, это OSGi вам не по душе или что?
RCP с его обилием синглтонов. Внутренние пакеты. Плохо продуманное и часто меняющееся API.
(еще три месяца назад я писал на базе Eclipse RCP коммерческий софт и сейчас радуюсь, что завязал — хоть эта платформа и лучшая)
B>>Жаль что JetBrains лезет вперёд батьки и вводит нестандартные конструкции. R>Есть потребность в контрактном программировании, а JDK на данный момент не предоставляет удобный инструментарий для того (даже контракты на утверждениях assert — это все же жуткий overhead), так что же — ждать у моря погоды?
Разумеется нет. Но такой инструментарий должен быть независимым от производителя IDE.
>Про java.constraint.Optional не понял, какой смысл в него вкладывается?
Декларируется в явном виде возможность не задавать значение поля. А вообще, если бы я решал, как это будет в Java SE, то позволил бы пользователям уточнять семантику ограничений (при условии непротиворечивости). Так чтобы, например, аннотация Optional позволяла описать пустой контейнер:
public class Profile {
@Optional PostalAddress address = new PostalAddress(); // optional = адрес не заполнен, хотя объект под него создан
}
При этом компилятор будет поддерживать часть базовой семантики (@Mandatory, @Length для инициализированных переменных...),
IDE будет добавлять свой анализ, а библиотеки приложения с аннотированной моделью — расширенную семантику (например с помощью валидаторов для проверки пользовательского ввода).
Здравствуйте, Baudolino, Вы писали:
B>>>Жаль что JetBrains лезет вперёд батьки и вводит нестандартные конструкции. R>>Есть потребность в контрактном программировании, а JDK на данный момент не предоставляет удобный инструментарий для того (даже контракты на утверждениях assert — это все же жуткий overhead), так что же — ждать у моря погоды? B>Разумеется нет. Но такой инструментарий должен быть независимым от производителя IDE.
И независимым от языка, потому как ждать у моря погоды тоже хреново. Особенно если у тебя частная задача, и встраивать её в язык программирования будет излишним.
Следовательно, нужен некий стандарт на представление кода, единый для компиляторов и других средств программирования (IDE, верификаторов, генераторов кода и пр.). Можно сделать такой стандарт для явы, но с одной стороны, ява будет развиваться дальше (и стандарт прийдётся менять), а с другой стороны, неплохо бы иметь ту-же функциональность и для других языков — как используемых вместе с java (вроде JSP), так и подобных языков (C#).
Единым стандартом сейчас является текстовое представление кода, которое не отвечает всем вышеупомянутым пожеланиям с одной стороны, а с другой стороны — неудобно для работы (всё равно и компилятор, и IDE, и генераторы кода преобразуют текст в AST — abstract syntax tree).
Таким образом, если мы хотим сделать расширяемое (в будущем и между языками в настоящем) стандартное представление, для анализа кода и прочих средств разработки — лучше отказаться от текстового представления и стандартизировать AST представление. Вот SymADE — это и есть такой проект.
Здравствуйте, Baudolino, Вы писали:
B>RCP с его обилием синглтонов.
Примеры и предложения по тому, как обойтись без них?
B>Внутренние пакеты. Плохо продуманное и часто меняющееся API.
org.eclipse.*.internal.*?
Если вы о том, то... вы читали рекомендации по тому, что не стоит пользоваться классами данных пакетов?
B>(еще три месяца назад я писал на базе Eclipse RCP коммерческий софт и сейчас радуюсь, что завязал — хоть эта платформа и лучшая)
Согласны, что лучшая платформа, но радуетесь, что завязали — очень непонятно. И какие есть альтернативы?
Здравствуйте, Baudolino, Вы писали:
B>Разумеется нет. Но такой инструментарий должен быть независимым от производителя IDE.
А, вы про наработки JetBrains? Не в курсе, как там. Oval же — просто библиотека, правда и требует потрошения кода аспектным компилятором.
B>Декларируется в явном виде возможность не задавать значение поля.
Все равно непонятно, чем это отличается от простой декларации переменной: умолчальным значением примитива или пустым значением для ссылки. Скажем, явную декларацию необходимости инициализации поля, хоть и разовую, хорошо обеспечивает immutable-модификатор final, который намного разумнее было бы сделать умолчальным — практичнее декларировать изменяемость, а не наоборот.
B>public class Profile { B>@Optional PostalAddress address = new PostalAddress(); // optional = адрес не заполнен, хотя объект под него создан
Какую смысловую нагрузку несет @Optional для поля address в классе Profile; то есть Profile знает, что его поле address фиктивно? Допустим... и что дальше, как это есть, чем это лучше null?
B>При этом компилятор будет поддерживать часть базовой семантики (@Mandatory, @Length для инициализированных переменных...), B>IDE будет добавлять свой анализ, а библиотеки приложения с аннотированной моделью — расширенную семантику (например с помощью валидаторов для проверки пользовательского ввода).
Что-то мне подсказывает, что от JCP такого счастья ждать в ближайшие годы, как и у моря погоды.
Hello, mkizub!
You wrote on Mon, 13 Aug 2007 15:30:26 GMT:
m> Таким образом, если мы хотим сделать расширяемое (в будущем и m> между языками в настоящем) стандартное представление, для анализа m> кода и прочих средств разработки — лучше отказаться от текстового m> представления и стандартизировать AST представление. Вот m> SymADE — это и есть такой проект.
Максим, ты уже притомил пиаром своего SymADE. Начинает напоминать культ N.
Здравствуйте, YК, Вы писали:
YК>Максим, ты уже притомил пиаром своего SymADE. Начинает напоминать культ N.
То есть, раз ты притомился, мне вообще замолкнуть в тряпочку?
Или пиарить то, что тебя ещё не притомило?
И лучше проконсультироваться с тобой, предварительно, не притомит ли тебя пиар Oval-а или ещё какой хрени, да?
Ты можешь внятно сформулировать, что тебя задело?
Hello, mkizub!
You wrote on Mon, 13 Aug 2007 16:18:46 GMT:
YК>> Максим, ты уже притомил пиаром своего SymADE. Начинает YК>> напоминать культ N.
m> То есть, раз ты притомился, мне вообще замолкнуть в тряпочку? m> Или пиарить то, что тебя ещё не притомило? m> И лучше проконсультироваться с тобой, предварительно, не притомит m> ли тебя пиар Oval-а или ещё какой хрени, да? m> Ты можешь внятно сформулировать, что тебя задело?
Меня ничего не задело. Просто не надо сунуть своего сфероконя в вещи, имеющиие к нему отдаленное отношение.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, Baudolino, Вы писали:
B>>RCP с его обилием синглтонов. R>Примеры и предложения по тому, как обойтись без них?
Вкратце — IoC. А детально — поля этой книги слишком маленькие.
B>>Внутренние пакеты. Плохо продуманное и часто меняющееся API. R>org.eclipse.*.internal.*? R>Если вы о том, то... вы читали рекомендации по тому, что не стоит пользоваться классами данных пакетов?
К сожалению, это не всегда возможно. В деталях, простите, сейчас не могу — конкретные грабли уже успел забыть.
B>>(еще три месяца назад я писал на базе Eclipse RCP коммерческий софт и сейчас радуюсь, что завязал — хоть эта платформа и лучшая) R>Согласны, что лучшая платформа, но радуетесь, что завязали — очень непонятно. И какие есть альтернативы?
Сменил место работы и теперь ругаюсь на Spring Альтератив пока не вижу. Eclipse хоть и сырая технология, но работающая и позволяющая делать очень многое.
Hello, mkizub!
You wrote on Mon, 13 Aug 2007 16:57:22 GMT:
YК>> Меня ничего не задело. Просто не надо сунуть своего сфероконя в YК>> вещи, имеющиие к нему отдаленное отношение.
m> Имеющего к этому прямое отношение, потому как решение данной m> проблемы было одной из основных мотиваций при написании SymADE.
Обобщать на основе мотиваций — это сильно
Языконезависимость для решения данной проблемы — а именно реализации контрактного программирования в Java — нафиг не нужна.
Здравствуйте, YК, Вы писали:
YК>Языконезависимость для решения данной проблемы — а именно реализации контрактного программирования в Java — нафиг не нужна.
Языконезависимость — это одна часть проблемы. Пусть она не волнует данного пользователя, но в неявном виде она присутствует для разработчика.
Я знаю несколько реализаций расширений для явы для решения данной проблемы — и все они не пользуются успехом.
Это такие компиляторы как JML (http://www.eecs.ucf.edu/~leavens/JML/), IntelliJ Idea, prototype implementation для JSR 308 и многие предыдущие, частично описанные здесь http://www.robert-tolksdorf.de/vmlanguages.html и много просто академических проектов с разработкой закончившейся написанием статьи и забытых.
Все эти решения, а равно и другие решения (вроде добавления синтаксического сахара, в виде enum-ов, foreach, work-by-contract расширений и пр.) не были практически никем использованы. По разным причинам, в том числе и тут упоминавшимся — не работает со стандартными тулзами, реализует "немного не то, что нужно". Сам этот топик заведён по той-же причине — вот надо человеку notnull — а для него надо либо язык менять, либо целый компилятор новый писать — и потом всё равно это никто пользовать не будет.
Так что решить проблему контрактного программирования в Java можно без работы с AST деревом. Только это решение, на практике, нафиг никому не нужно.
Впрочем, не всё так печально — есть JSR 305, 308 и другие, расширяющие функциональность аннотаций и добавляющие средства мета-программирования в яву. Лет через 5 у вас будет стандартный для явы способ мета-программирования, основанный на AST между прочим. Тогда вам захочется большего, и средства вроде N или S вас не будут раздражать, а будет раздражать ограниченность явовских средств. Вот тогда и поговорим.
ЗЫ Кстати, мне тут мысля пришла в голову, наглядно объясняющая почему SymADE, Nemerle, Scala и иже с ними — не смогут вытеснить C#, Java и т.п. И заодно — как их надо продвигать, чтоб они стали мэйнстримом. Так что я пошёл работать, не буду тебя лишний раз раздражать.
Здравствуйте, mkizub, Вы писали:
M>ЗЫ Кстати, мне тут мысля пришла в голову, наглядно объясняющая почему SymADE, Nemerle, Scala и иже с ними — не смогут вытеснить C#, Java и т.п. И заодно — как их надо продвигать, чтоб они стали мэйнстримом. Так что я пошёл работать, не буду тебя лишний раз раздражать.
Действительно интересно, почему?
Здравствуйте, Baudolino, Вы писали:
B>Разумеется нет. Но такой инструментарий должен быть независимым от производителя IDE.
Скажите это тем кто пользуется визуальными редакторами GUI. Которые поризводители IDE штампуют кто во что горазд без какой-либо совместимости.
Hello, mkizub!
You wrote on Mon, 13 Aug 2007 18:54:06 GMT:
YК>> Языконезависимость для решения данной проблемы — а именно YК>> реализации контрактного программирования в Java — нафиг не YК>> нужна.
m> Языконезависимость — это одна часть проблемы. Пусть она не волнует m> данного пользователя, но в неявном виде она присутствует для m> разработчика. m> Я знаю несколько реализаций расширений для явы для решения данной m> проблемы — и все они не пользуются успехом. m> Это такие компиляторы как JML m> (http://www.eecs.ucf.edu/~leavens/JML/), IntelliJ Idea, prototype m> implementation для JSR 308 и многие предыдущие, частично описанные m> здесь http://www.robert-tolksdorf.de/vmlanguages.html и много m> просто академических проектов с разработкой закончившейся m> написанием статьи и забытых.
m> Все эти решения, а равно и другие решения (вроде добавления m> синтаксического сахара, в виде enum-ов, foreach, work-by-contract m> расширений и пр.) не были практически никем использованы. По m> разным причинам, в том числе и тут упоминавшимся — не работает со m> стандартными тулзами, реализует "немного не то, что нужно".
О чем мы вообще говорим?
Контрактное программирование предполагает в первую очередь наличия трех вещей:
a) предусловий
б) постусловий
в) инвариантов класса
и соответственно требования выполнять контракт, формально выраженный для клиента предусловиями, а для поставщика — постусловиями. Об автоматизированном доказательстве корректности здесь речь не идет, это другая область.
Предусловия и постусловия элементарно реализуются при помощи аспектов. Проверка инварианта — тоже, в том смысле что точки для такой проверки есть (разумеется, непосредственно проверка инварианта требует некоторых усилий).
Так причем здесь AST и SymADE?
m> Сам этот топик заведён по той-же причине — вот надо человеку notnull m> — а для него надо либо язык менять, либо целый компилятор новый m> писать — и потом всё равно это никто пользовать не будет.
Там речь идет о проверке компилятором. К контрактному программированию это имеет отношение только тем, что формально выражается предусловие, т.е. контракт. Последующая проверка компилятором — это автоматическое обнаружение ошибок, верификация — называйте как хотите, только это не контрактное программирование. Последнее предполагает знание клиента или поставщика о контракте, и осознанное следование этому контракту.
m> Так что решить проблему контрактного программирования в Java можно m> без работы с AST деревом. Только это решение, на практике, нафиг m> никому не нужно.
Такие решения есть, они работают и не нуждаются ни в каких SymADE. Заканчивай с пиаром.
m> Впрочем, не всё так печально — есть JSR 305, 308 и другие, m> расширяющие функциональность аннотаций и добавляющие средства m> мета-программирования в яву. Лет через 5 у вас будет стандартный m> для явы способ мета-программирования, основанный на AST между m> прочим. Тогда вам захочется большего, и средства вроде N или S вас m> не будут раздражать, а будет раздражать ограниченность явовских m> средств. Вот тогда и поговорим.
Я говорю о конкретной вещи — контрактном программировании. Причем здесь мета-программирование? Чтобы в очередной раз SymADE упомянуть?
Здравствуйте, YК, Вы писали:
YК>Там речь идет о проверке компилятором. К контрактному программированию это имеет отношение только тем, что формально выражается предусловие, т.е. контракт. Последующая проверка компилятором — это автоматическое обнаружение ошибок, верификация — называйте как хотите, только это не контрактное программирование. Последнее предполагает знание клиента или поставщика о контракте, и осознанное следование этому контракту.
а) топик о notnull — верификации условия на этапе компиляции или выполнения,
б) про контрактное программирование ты завёл речь, и естественно я решил, что ты этот термин употребляешь не как work-by-contract технику Эйфеля, а в более общем смысле.
Так что выбирай — или твой изначальный заезд с контрактным программированием не в тему, или мы говорим об общем случае контрактов, которые работают и в compile time. Как выберешь — так и продолжим.
Здравствуйте, Blazkowicz, Вы писали:
>>Разумеется нет. Но такой инструментарий должен быть независимым от производителя IDE. B>Скажите это тем кто пользуется визуальными редакторами GUI. Которые поризводители IDE штампуют кто во что горазд без какой-либо совместимости.
Наверное под словом "должен" он имел в виду идеальный для пользователя вариант, а не более распространённый — "хотели как лучше, а получилось как всегда".
Hello, mkizub!
You wrote on Tue, 14 Aug 2007 09:23:05 GMT:
YК>> Там речь идет о проверке компилятором. К контрактному YК>> программированию это имеет отношение только тем, что формально YК>> выражается предусловие, т.е. контракт. Последующая проверка YК>> компилятором — это автоматическое обнаружение ошибок, YК>> верификация — называйте как хотите, только это не контрактное YК>> программирование. Последнее предполагает знание клиента или YК>> поставщика о контракте, и осознанное следование этому YК>> контракту.
m> а) топик о notnull — верификации условия на этапе компиляции или m> выполнения, m> б) про контрактное программирование ты завёл речь, и естественно я m> решил, что ты этот термин употребляешь не как work-by-contract m> технику Эйфеля, а в более общем смысле.
Мало что ты там решил. Есть совершенно четкое определение контрактного программирования, данное Мейером. И именно о контрактном программировании шла речь в этой ветке, а не о верификации notnull.
m> Так что выбирай — или твой изначальный заезд с контрактным m> программированием не в тему, или мы говорим об общем случае m> контрактов, которые работают и в compile time. Как выберешь — так m> и продолжим.
Мне выбирать незачем — речь шла о контрактном программировании. Ты бы лучше следил за темой разговора.
Здравствуйте, mkizub, Вы писали:
M>а) топик о notnull — верификации условия на этапе компиляции или выполнения,
А при чем время выполнения-то? ИМХО, про него речь не шла вообще.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
