Adding notnull to the Java Programming Language
От: Dmytro Sheyko  
Дата: 11.08.04 03:07
Оценка: 860 (21) -2
Статья:
Adding notnull to the Java Programming Language
Автор(ы): Dmytro Sheyko
Дата: 08.08.2004
В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.


Авторы:
Dmytro Sheyko

Аннотация:
В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.
--
Дмитро
Re: Adding notnull to the Java Programming Language
От: Eugeny__ Украина  
Дата: 11.08.04 07:30
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Статья:



А>Авторы:

А>Dmytro Sheyko

А>Аннотация:

А>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.


Очень интересная идея. Плохо только, что Sun ее в ближайших версиях компиляторов не реализует (если реализует вообще).

Если по смыслу, то не уверен, что лучше использовать аннотации для объявления notnull. Да, проблема компиляции старых программ, в которых использовалось "notnull" в качестве идентификатора есть, но ,имхо, она не столь уж и значительна. Использование ключевого слова как-то более естественно.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re: Adding notnull to the Java Programming Language
От: adontz Грузия http://adontz.wordpress.com/
Дата: 12.08.04 01:25
Оценка:
Здравствуйте, Аноним, Вы писали:

Я на Java не пишу,но проблема общая для всех языков, так что статья была всё равно интересна.
Особенно стало интересно как за счёт компилятора решить подобную задачу в другия языках.
А вот почему автор даже не зарегистрировался на сайте не понятно.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[2]: Adding notnull to the Java Programming Language
От: Бекетов Роман aka Yaiu Россия  
Дата: 12.08.04 09:45
Оценка:
Здравствуйте, adontz, Вы писали:

A>Я на Java не пишу,но проблема общая для всех языков, так что статья была всё равно интересна.

A>Особенно стало интересно как за счёт компилятора решить подобную задачу в другия языках.
A>А вот почему автор даже не зарегистрировался на сайте не понятно.


dshe ...
Нужно знать инструмент, который используешь
Re: Adding notnull to the Java Programming Language
От: Аноним  
Дата: 17.08.04 18:51
Оценка:
Здравствуйте, Dmytro Sheyko, Вы писали:

DS>Статья:



DS>Авторы:

DS> Dmytro Sheyko

DS>Аннотация:

DS>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

Дмитрий, на мой взгляд можно обойтись без изобретения нового модификатора.
Возможно вы в курсе, но если нет, то советую почитать например книжку Мартина Фоулера (Martin Fowler) Refactoring. Improving the Design of Existing Code. Там в частности расматривается решения проблем с нулевыми указателями (Introducing Null Object и Special case design pattern). На мой взгляд упомянутые там решения изящнее и носят более общий характер. Но тем не менее, мне было интересно прочитать и Вашу статью.

Cпасибо
Re[2]: Adding notnull to the Java Programming Language
От: dshe  
Дата: 18.08.04 07:38
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Dmytro Sheyko, Вы писали:


DS>>Статья:



DS>>Авторы:

DS>> Dmytro Sheyko

DS>>Аннотация:

DS>>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

А>Дмитрий, на мой взгляд можно обойтись без изобретения нового модификатора.

А>Возможно вы в курсе, но если нет, то советую почитать например книжку Мартина Фоулера (Martin Fowler) Refactoring. Improving the Design of Existing Code. Там в частности расматривается решения проблем с нулевыми указателями (Introducing Null Object и Special case design pattern). На мой взгляд упомянутые там решения изящнее и носят более общий характер. Но тем не менее, мне было интересно прочитать и Вашу статью.

Cпасибо за интерес к статье.

На мой взгляд, паттерны Null Object и Special Case не являются исключающими альтернативами notnull'у. Они (паттерны и notnull) могут прекрасно уживаться вместе. notnull претендует на то, чтобы быть средством дополнительного контроля на этапе компиляции, таким же как и типы. Тогда как Null Object — это способ избежать многократных проверок на null. Конечно, можно принципиально отказаться от использования null литерала в пользу Null Object'ов. Однако, это не всегда возможно и целесообразно.
--
Дмитро
Re: Adding notnull to the Java Programming Language
От: dshe  
Дата: 19.08.04 06:31
Оценка:
Здравствуйте, Dmytro Sheyko, Вы писали:

DS>Статья:



DS>Авторы:

DS> Dmytro Sheyko

DS>Аннотация:

DS>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

Кстати, кто-нибудь знает Open Source Java-компилятор, поддерживающий аннотации (и, желательно, генерики)?
--
Дмитро
Re[2]: Adding notnull to the Java Programming Language
От: Аноним  
Дата: 27.11.04 16:15
Оценка: +1
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Dmytro Sheyko, Вы писали:


DS>>Статья:



DS>>Авторы:

DS>> Dmytro Sheyko

DS>>Аннотация:

DS>>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

А>Дмитрий, на мой взгляд можно обойтись без изобретения нового модификатора.

А>Возможно вы в курсе, но если нет, то советую почитать например книжку Мартина Фоулера (Martin Fowler) Refactoring. Improving the Design of Existing Code. Там в частности расматривается решения проблем с нулевыми указателями (Introducing Null Object и Special case design pattern). На мой взгляд упомянутые там решения изящнее и носят более общий характер. Но тем не менее, мне было интересно прочитать и Вашу статью.

А>Cпасибо


Я б советовал написать мало-мальски серъездный код (большую систему) с использованием этого синтаксиса. Я думаю что в ней будут постоянные приведения к notnull типу.....
Re: Adding notnull to the Java Programming Language
От: Волк-Призрак Россия http://ghostwolf.newmail.ru
Дата: 29.11.04 21:51
Оценка: 5 (1)
Здравствуйте, Dmytro Sheyko, Вы писали:

DS>Статья:



DS>Авторы:

DS> Dmytro Sheyko

DS>Аннотация:

DS>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.


Возможно, я высказываю дилетанскую мысль, но я бы предложил иную концепцию.
ключевое слово nullable для объектных переменых (или как правильнее сказать?),
которым можно присвоить null, Остальные объектные переменные пусть считатся not initialized с соответсвующем сообщением компилятора, если объектной переменной при создании или позже присваиваешь явно null или
когда обычной объектной переменной присваиваешь помеченное nullable (результат nullable-функции, выражения с участием nullable-переменых, итп итд), пишется uncaught NullPointerException. на этапе компиляции.
Мне кажется это проще. Но конечно это должно быть с совместью.Т. е. для классов, помеченых notnull, можно сделать либо Ваш вариант либо то, о чём говорю я. А остальной код пусть работает в "старой" среде умолчаний и "правил игры".
ЗЫ:
Я вообще не люблю null присваивать.
А исключения я обрабатываю try{code}catch(Throwable t){errorprocessing) (в конце (или вместо) списка у меня частенько "Throwable перехватывается". Это хорошо или плохо? (В плане эффективности, устойчивости/стабильности кода ?)
while(Life.getClass().getClassLoader()==Religion.GOD){Life.be();};
Скажи .net корпорации Microsoft! (c) ghostwolf 2004
7 раз поищи в стандартной библиотеке, 1 раз накодь своё.
Re[2]: Adding notnull to the Java Programming Language
От: dshe  
Дата: 30.11.04 08:09
Оценка:
Здравствуйте, Волк-Призрак, Вы писали:

ВП>Возможно, я высказываю дилетанскую мысль, но я бы предложил иную концепцию.

ВП>ключевое слово nullable для объектных переменых (или как правильнее сказать?),
ВП>которым можно присвоить null, Остальные объектные переменные пусть считатся not initialized с соответсвующем сообщением компилятора, если объектной переменной при создании или позже присваиваешь явно null или
ВП> когда обычной объектной переменной присваиваешь помеченное nullable (результат nullable-функции, выражения с участием nullable-переменых, итп итд), пишется uncaught NullPointerException. на этапе компиляции.
ВП>Мне кажется это проще.

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

ВП>Но конечно это должно быть с совместью.Т. е. для классов, помеченых notnull, можно сделать либо Ваш вариант либо то, о чём говорю я. А остальной код пусть работает в "старой" среде умолчаний и "правил игры".


Правильно ли я тонял, что ты предлагаешь классы, в которых предполагается использование данного расширения явно помечать notnull? И в таких классах все ссылочные переменные (аргументы и возвращаемые значения ??) по-умолчанию становятся ненулевыми? Я не думаю, что это хорошо поскольку для того, чтобы понять смысл какого-либо объявления (поля или метода) необходимо будет еще и смотреть, с каким модификатором был объявлен класс. Также простая установка/снятие notnull модификатора с класса будет приводить к радикальному изменению семантики объявлений, содержащихся в классе.
--
Дмитро
Re[3]: Adding notnull to the Java Programming Language
От: Волк-Призрак Россия http://ghostwolf.newmail.ru
Дата: 30.11.04 11:28
Оценка:
Здравствуйте, dshe, Вы писали:

D>Здравствуйте, Волк-Призрак, Вы писали:



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


За модификаторами будет смотреть синтаксический анализатор и компилятор. А вообще этот notnull в любом виде может стать очередной красной тряпкой, вроде Windows vs Linux, или "софтверным патентам — да!" vs "софтыерным патентам — смерть!".
Документировать такое (использование notnull) надо, разумеется, особенно, "на видном месте.
И такой вопрос при том виде notnull-класса появляется — можно ли ссылочной переменной notnull-класса присвоить null? По логике этого расчирения (notnull classes) — нет. А по логике сериализации — да.
Так что для notnull class должно использоваться ключерое слово default, после которого идёт выражение, возвращающее ссылку того класса, который объявляется.
Например вот так:
public notnull class Person implements Serializable default new Person("","","") {

private String firstname="";
private String middlename="";
private String lastname="";
private nullable WorkPlace thework=null;

public Person(String first,String last, String middle){
//бубубу, ляляя, присвойте имена
thework=Workplace.nojob;//nojob==null, may be.
}

public Person(String first,String last, String middle, Workplace work){
//бубубу, ляляя, присвойте имена
workplace=work;
}

}

Но тогда потребуется ключевое слово ___isdefault;
boolean var1=___isdefault referenceexpression;
Или конструкции типа
boolean var2=reference.equals(default);
Но тогда notnull классы должный всегда сопровождаться default.
Знвчит можно убрать слово notnull из объявления класса а оставить default.
однако тут есть вот какая загвозка.
class Person default new Person()

Person(){
//Инициализация по умолчанию.
}

Person parent;

Person(string name, Person parent)
{};

}

всё, приехали. бесконечный цикл инициализации — parent нельзя присвоить null.
Компилятор нужно "научить" таким ситуациям:
Если в классе с default есть нестатические члены того же типа, что и объявляемый класс,
то выдать ошибку наподобие
"Infinity initialization error: reference variable parent mast be declared as nullable.".
while(Life.getClass().getClassLoader()==Religion.GOD){Life.be();};
Скажи .net корпорации Microsoft! (c) ghostwolf 2004
7 раз поищи в стандартной библиотеке, 1 раз накодь своё.
Re: Adding notnull to the Java Programming Language
От: dshe  
Дата: 30.11.04 13:03
Оценка:
Здравствуйте, Dmytro Sheyko, Вы писали:

DS>Статья:



DS>Авторы:

DS> Dmytro Sheyko

DS>Аннотация:

DS>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

Кстати, вот несколько интересных ссылок по теме:

Declaring and Checking Non-null Types in an Object-Oriented Language

Bug ID 5030232: Add Nice Option types to Java to prevent NullPointerExceptions
--
Дмитро
Re[4]: Adding notnull to the Java Programming Language
От: dshe  
Дата: 30.11.04 16:02
Оценка:
Здравствуйте, Волк-Призрак, Вы писали:

ВП>Здравствуйте, dshe, Вы писали:


D>>Здравствуйте, Волк-Призрак, Вы писали:



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


ВП>За модификаторами будет смотреть синтаксический анализатор и компилятор.


Речь идет не о компиляторе, а о человеке (разработчике). Уточню свою мысль -- я полагаю, что у разработчиков это вызовет ряд неудобств, поскольку такое объявление
    // ...
    public void method(String arg) {
        // ...
    }
    // ...

Имеет разный смысл в зависимости от того, находится ли оно в notnull классе или в классе "старого стиля". Метод либо принимает ненулевой параметр (в notnull классе), либо может принимать null (в классе "старого стиля").

ВП>Например вот так:

ВП>
ВП>public notnull class Person implements Serializable default new Person("","","") {

ВП>private String firstname="";
ВП>private String middlename="";
ВП>private String lastname="";
ВП>private nullable WorkPlace thework=null;

ВП>public Person(String first,String last, String middle){
ВП>//бубубу, ляляя, присвойте имена
ВП>thework=Workplace.nojob;//nojob==null, may be.
ВП>}

ВП>public Person(String first,String last, String middle, Workplace work){
ВП>//бубубу, ляляя, присвойте имена
ВП>workplace=work;
ВП>}

ВП>}
ВП>


Еще раз хочу уточнить смысл выделенной конструкции. Она означает, что перечисленными значениями будет инициализироваться instance переменные до вызова конструктора? Какие выгоды это дает? Не проще ли потребовать инициализировать поля сразу при объявлении? (так, на мой взгляд даже будет наглядее, поскольку в приведенном тобой примере не очевидно, какая из приведенных в default выражении пустых строк какой переменной соответствует). Могут ли быть более сложные выражения, чем строки, в default выражении? (Полагаю, что должны быть, поскольку иначе notnull расширение будет иметь смысл исключительно для класса java.lang.String). А как быть со статическими переменными?

ВП>всё, приехали. бесконечный цикл инициализации — parent нельзя присвоить null.

ВП>Компилятор нужно "научить" таким ситуациям:
ВП>Если в классе с default есть нестатические члены того же типа, что и объявляемый класс,
ВП>то выдать ошибку наподобие
ВП> "Infinity initialization error: reference variable parent mast be declared as nullable.".

Я не вижу особого смысла накладывать подобные ограничения. Что плохого в том, чтобы переменная parent была notnull? Единственное, нужно проверить, чтобы в конструкторе она инициализировалась ненулевым значением (что и делает предложенная мной реализация).
--
Дмитро
Re: Adding notnull to the Java Programming Language
От: Blazkowicz Россия  
Дата: 04.07.05 13:09
Оценка: 6 (3)
Здравствуйте, Dmytro Sheyko, Вы писали:

DS>Статья:

DS>Adding notnull to the Java Programming Language
Автор(ы): Dmytro Sheyko
Дата: 08.08.2004
В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.


DS>Авторы:

DS> Dmytro Sheyko

DS>Аннотация:

DS>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

А пока в Sun думают...
Re[2]: Adding notnull to the Java Programming Language
От: aefimov Россия
Дата: 12.07.05 07:39
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>А пока в Sun думают...


Я думаю они сделают это, JetBrains сроде как может им советовать. @SuppressWarning же появился.
Вот я думаю появится и @Nullable с @NotNull. По крайней мере я ими уже пользуюсь.
Re: Adding notnull to the Java Programming Language
От: caustic http://commitq.com/
Дата: 09.08.05 09:14
Оценка: 5 (1)
Здравствуйте, Dmytro Sheyko, Вы писали:

DS>Статья:

DS>Adding notnull to the Java Programming Language
Автор(ы): Dmytro Sheyko
Дата: 08.08.2004
В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.


DS>Авторы:

DS> Dmytro Sheyko

DS>Аннотация:

DS>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

В статье часто упоминается слово "контракт", для тех кто не в курсе, рекомендую для общего развития познакомиться с языком Eiffel и техникой Design by Contract.
Здесь можно прочитать про iContract -- реализацию Design by Contract для Java.
Судя по всему, DBC кроме прочих позволяет так же вводить окраничение и на not null.
Например:

/**
 * @inv firstName != null
 * @inv lastName  != null
 */
public class Person {
    private String firstName;
    private String lastName;

    /**
     * @pre firstName != null
     */
    public void setFirstName(String firstName) {
        return this.firstName = firstName;
    }

    /**
     * @post return != null
     */
    public String getFirstName() {
        return firstName;
    }
    // . . .
}


Здесь инвариант класса запрещает нули в переменных firstName и lastName. Предусловие метода setFirstName запрещает передавать ему нуль в параметре, а постусловие метода getFirstName запрещает ему возвращать нуль.
Компилятор анализируя инварианты, предусловия и постусловия мог бы получить столько же информации, сколько из ключевых слов not null или аннотаций @NotNull. Кроме того, DBC позволяет намного больше, чем просто not null.
Re[2]: Adding notnull to the Java Programming Language
От: dshe  
Дата: 09.08.05 15:24
Оценка:
Здравствуйте, caustic, Вы писали:

C>Компилятор анализируя инварианты, предусловия и постусловия мог бы получить столько же информации, сколько из ключевых слов not null или аннотаций @NotNull. Кроме того, DBC позволяет намного больше, чем просто not null.


Верно. Тем не менее iContract не проверяет "правильность" во время компиляции, а просто добавляет код, который делает необходимые проверки уже на этапе выполнения.
--
Дмитро
Re: Adding notnull to the Java Programming Language
От: iZEN СССР  
Дата: 11.08.05 13:31
Оценка:
Здравствуйте, Dmytro Sheyko, Вы писали:

DS>Статья:

DS>Adding notnull to the Java Programming Language
Автор(ы): Dmytro Sheyko
Дата: 08.08.2004
В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.


DS>Авторы:

DS> Dmytro Sheyko

DS>Аннотация:

DS>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.
Это ничего не даёт: появляется ещё одна сущность-квазитип "NotNULL", за объектами которой тоже нужно присматривать.
Введение новых ключевых слов — это просто затенение проблемы разработчиков.

Решение проблемы — сходно с намеренным отказом от семантики throws в сигнатурах методов .Net.
Re[2]: Adding notnull to the Java Programming Language
От: iZEN СССР  
Дата: 11.08.05 13:32
Оценка:
Решение проблемы таким образом сходно с намеренным отказом от семантики throws в сигнатурах методов .Net, что очень печально.
Re[3]: Adding notnull to the Java Programming Language
От: caustic http://commitq.com/
Дата: 11.08.05 13:37
Оценка:
Здравствуйте, iZEN, Вы писали:

ZEN>Решение проблемы таким образом сходно с намеренным отказом от семантики throws в сигнатурах методов .Net, что очень печально.


Что печально, отказ от семантики throws в сигнатурах методов? Я бы так не сказал.
Re[4]: Adding notnull to the Java Programming Language
От: iZEN СССР  
Дата: 11.08.05 14:02
Оценка:
Здравствуйте, caustic, Вы писали:

C>Здравствуйте, iZEN, Вы писали:


ZEN>>Решение проблемы таким образом сходно с намеренным отказом от семантики throws в сигнатурах методов .Net, что очень печально.


C>Что печально, отказ от семантики throws в сигнатурах методов? Я бы так не сказал.

А я так говорю.

Ну ладно, не будем далеко уходить от темы.
В подходе, описанном в статье, исключение NullPointerException никто не отменяет, просто его переносят поближе к прикладному коду, в то же время пытаясь часть проблемы переложить на компилятор (этап компиляции).
Смешно.
Придумывают новое ключевое слово и разделяют одну проблему на две проблемы.
Смешно.

Я говорю, что исключение NullPointerException не на пустом месте появляется (каламбур: хотя как раз-таки на пустом). Именно это исключение — важный знак плохого дизайна. И дело решения проблемы с нулевыми ссылками лежит исключительно в плоскости прикладного кода — его дизайна. Не надо перекладывать надуманную проблему низкоквалифицированных кодеров на среду программирования.
Не получится.

Не нужно подстилать соломку там, где под ногами болото, рано или поздно выплывут другие связанные с этим проблемы, а вы (или кто-то после вас) погрязнете в их решении (утонете).
Re[5]: Adding notnull to the Java Programming Language
От: Blazkowicz Россия  
Дата: 11.08.05 14:22
Оценка: +1
Здравствуйте, iZEN, Вы писали:

C>>Что печально, отказ от семантики throws в сигнатурах методов? Я бы так не сказал.

ZEN>А я так говорю.
В священные войны.


ZEN>Ну ладно, не будем далеко уходить от темы.

ZEN>В подходе, описанном в статье, исключение NullPointerException никто не отменяет, просто его переносят поближе к прикладному коду, в то же время пытаясь часть проблемы переложить на компилятор (этап компиляции).
ZEN>Смешно.
Интересная оценка.

ZEN>Придумывают новое ключевое слово и разделяют одну проблему на две проблемы.

ZEN>Смешно.
Где вторая проблема?

ZEN>Я говорю, что исключение NullPointerException не на пустом месте появляется (каламбур: хотя как раз-таки на пустом). Именно это исключение — важный знак плохого дизайна.

Всегда ли нам приходится иметь дело с таким хорошим дизайном что в нем не встречаются NPE?

ZEN>И дело решения проблемы с нулевыми ссылками лежит исключительно в плоскости прикладного кода — его дизайна. Не надо перекладывать надуманную проблему низкоквалифицированных кодеров на среду программирования.

ZEN>Не получится.
Да ладно, до этого у всех IDE получалось, а тут бац и не получится. Почему не получится? IDE призваны решать проблемы кодера. Чем они успешно и занимаются.

ZEN>Не нужно подстилать соломку там, где под ногами болото, рано или поздно выплывут другие связанные с этим проблемы, а вы (или кто-то после вас) погрязнете в их решении (утонете).

Это предсказание? Или опыт? Если опыт то тогда делись какие именно проблемы всплывут?
Re[6]: Adding notnull to the Java Programming Language
От: iZEN СССР  
Дата: 11.08.05 18:49
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

iZEN>>Придумывают новое ключевое слово и разделяют одну проблему на две проблемы.

iZEN>>Смешно.
B>Где вторая проблема?
Там же, где и была: обрабатывать NullPointerException всё-таки нужно.

iZEN>>Я говорю, что исключение NullPointerException не на пустом месте появляется (каламбур: хотя как раз-таки на пустом). Именно это исключение — важный знак плохого дизайна.

B>Всегда ли нам приходится иметь дело с таким хорошим дизайном что в нем не встречаются NPE?
Почему NullPointerException не встречается в средах програмирования на Java? Это же целые конгломераты классов и объектов с гибкой системой управления кодом.

iZEN>>И дело решения проблемы с нулевыми ссылками лежит исключительно в плоскости прикладного кода — его дизайна. Не надо перекладывать надуманную проблему низкоквалифицированных кодеров на среду программирования.

iZEN>>Не получится.
B>Да ладно, до этого у всех IDE получалось, а тут бац и не получится. Почему не получится? IDE призваны решать проблемы кодера. Чем они успешно и занимаются.
Я не про IDE, а вообще — про среду исполнения и среду создания кода, включающие в себя рантайм, компилятор, инструменты отладки и сборки.

iZEN>>Не нужно подстилать соломку там, где под ногами болото, рано или поздно выплывут другие связанные с этим проблемы, а вы (или кто-то после вас) погрязнете в их решении (утонете).

B>Это предсказание? Или опыт? Если опыт то тогда делись какие именно проблемы всплывут?
Это опыт из Delphi 3->5->7.
Проблемы:
1) Управляемость исходным кодом может быть нарушена — совмещение старого и нового кода: не плодите сущностей почём зря, ими придётся управлять;
2) Потенциальная угроза "несрабатывания" защитного механизма вследствие такой же квалификации программиста, какая у него была до нововведений: человеческий фактор;
3) Новое ключевое слово и усложнение средств разработки/компиляции/отладки.
Re[7]: Adding notnull to the Java Programming Language
От: dshe  
Дата: 12.08.05 06:44
Оценка:
Здравствуйте, iZEN, Вы писали:

B>>Где вторая проблема?

ZEN>Там же, где и была: обрабатывать NullPointerException всё-таки нужно.

Вообще-то, лично я -- стронник подхода fail fast, т.е. ошибки в программе должны обнаруживать себя "во весь голос" и как можно раньше. Исключения типа NullPointerException вовсе не нужно как-то обрабатывать, они просто не должны возникать. Едиственная причина, по которой подобного рода исключения могут обрабатываться, -- это для более ранней и точной диагностики ошибки. Что касается описываемого в статье расширения компилятора, то оно позволяет такие ошибки (по крайней мере часть из них), обнаруживать еще раньше, на этапе компиляции.

iZEN>>>Я говорю, что исключение NullPointerException не на пустом месте появляется (каламбур: хотя как раз-таки на пустом). Именно это исключение — важный знак плохого дизайна.

B>>Всегда ли нам приходится иметь дело с таким хорошим дизайном что в нем не встречаются NPE?
ZEN>Почему NullPointerException не встречается в средах програмирования на Java? Это же целые конгломераты классов и объектов с гибкой системой управления кодом.

iZEN>>>И дело решения проблемы с нулевыми ссылками лежит исключительно в плоскости прикладного кода — его дизайна. Не надо перекладывать надуманную проблему низкоквалифицированных кодеров на среду программирования.


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

Проанализировав код я пришел к выводу, что все ссылочные значения можно разделить на два вида: те, которые могут принимать нулевое значение, и те, которые не могут. И большой риск возникновения NPE появляется тогда, когда с потенциально нулевыми значениями работают так, как будто, они никогда не могут быть null'ом. Т.е. когда разница между этими двумя видами ссылочных значений игнорируется. В общем-то, она всегда была, просто теперь она стала явной.

iZEN>>>Не нужно подстилать соломку там, где под ногами болото, рано или поздно выплывут другие связанные с этим проблемы, а вы (или кто-то после вас) погрязнете в их решении (утонете).

B>>Это предсказание? Или опыт? Если опыт то тогда делись какие именно проблемы всплывут?
ZEN>Это опыт из Delphi 3->5->7.
ZEN>Проблемы:
ZEN>1) Управляемость исходным кодом может быть нарушена — совмещение старого и нового кода: не плодите сущностей почём зря, ими придётся управлять;

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

ZEN>2) Потенциальная угроза "несрабатывания" защитного механизма вследствие такой же квалификации программиста, какая у него была до нововведений: человеческий фактор;


Да, есть такая угроза. Также как и есть шанс "срабатывания".

ZEN>3) Новое ключевое слово и усложнение средств разработки/компиляции/отладки.


Данное расширение действительно приводит в той или иной степени к усложнению инструментальных средств. Тем не менее, эта задача вполне реальна. В качестве доказательства, я привел код экспериментального компилятора.
--
Дмитро
Re: Adding notnull to the Java Programming Language
От: caustic http://commitq.com/
Дата: 19.10.05 09:21
Оценка:
Здравствуйте, Dmytro Sheyko, Вы писали:

DS>Статья:

DS>Adding notnull to the Java Programming Language
Автор(ы): Dmytro Sheyko
Дата: 08.08.2004
В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.


DS>Авторы:

DS> Dmytro Sheyko

DS>Аннотация:

DS>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

Между делом случайно нашел интересный баг 4449383 в Sun Bug Database:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4449383

Bug ID: 4449383
Votes 521
Synopsis Support For 'Design by Contract', beyond "a simple assertion facility"
Category java:specification
Reported Against 1.3
State In progress, request for enhancement
Submit Date 23-APR-2001
Description слишком много чтобы писать сюда, но в двух словах, разработчики хотят Design by Contract в Java.

Там же в коментариях есть такая вот запись:

Submitted On 04-MAY-2001
Ixchel

It may be quite difficult to implement this unless feature
request #4211070 ("Java should support const parameters,
like C++, for code maintenance") is also approved.

I would also like to see a way to declare certain object
references (fields, method parameters, local variables,
etc.) to be guaranteed to be non-null. This could be part
of a design-by-contract proposal, or a separate proposal.
It would be supported by data flow tracing in the compiler
(similar to what's used now to detect unassigned final
variables) to detect possible violations. For instance:


notnull String foo = "abc"; // foo can never be null
foo = null; // Compiler error here
foo = "def"; // No Compiler error here
String bar = getSomePossiblyNullString();
foo = bar; // Compiler error here
if (bar != null)
    foo = bar;  // No compiler error here


Re[2]: Adding notnull to the Java Programming Language
От: iZEN СССР  
Дата: 19.10.05 13:01
Оценка:
Здравствуйте, caustic, Вы писали:

C>Здравствуйте, Dmytro Sheyko, Вы писали:


DS>>Статья:

DS>>Adding notnull to the Java Programming Language
Автор(ы): Dmytro Sheyko
Дата: 08.08.2004
В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.


DS>>Авторы:

DS>> Dmytro Sheyko

DS>>Аннотация:

DS>>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

C>Между делом случайно нашел интересный баг 4449383 в Sun Bug Database:


C>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4449383


C>Bug ID: 4449383

<...>
Да. До Eiffel, у которого Java переняла некоторые черты, ещё ползти и ползти.
Re[2]: Adding notnull to the Java Programming Language
От: caustic http://commitq.com/
Дата: 19.10.05 18:07
Оценка:
Здравствуйте, caustic, Вы писали:

C>Здравствуйте, Dmytro Sheyko, Вы писали:


DS>>Статья:

DS>>Adding notnull to the Java Programming Language
Автор(ы): Dmytro Sheyko
Дата: 08.08.2004
В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.


DS>>Авторы:

DS>> Dmytro Sheyko

DS>>Аннотация:

DS>>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

C>Между делом случайно нашел интересный баг 4449383 в Sun Bug Database:


C>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4449383


C>Bug ID: 4449383

C>Votes 521
C>Synopsis Support For 'Design by Contract', beyond "a simple assertion facility"
C>Category java:specification
C>Reported Against 1.3
C>State In progress, request for enhancement
C>Submit Date 23-APR-2001
C>Description слишком много чтобы писать сюда, но в двух словах, разработчики хотят Design by Contract в Java.

В очередной раз меня посетила гениальная идея -- Design by Contract реализуется элементарно через XDoclet и AspectJ. XDoclet извлекает информацию о пред-, постусловиях и инвариантах из JavaDoc тэгов и генерирует AspectJ файлы аспектов, которые эти самые инварианты и реализуют незаметно для javaс компилятора. Это конечно требует дополнительных шагов компиляции, но совсем не сложно написать простенький плагин к мавену, который это все будет автоматизировать.
Я уже начал пускть слюни как я стану знаменитым и богатым запатентовав свою идею, но в очередной раз меня очень жестоко обломал гугль. Уже существует проект barter, который работает именно так, как я описал, но без мавена.
Кроме того, есть еще один проект contract4j, который использует анотации из пятой Java и Annotation Processing Tool (APT) для описания пре- и постусловий с инвариантами.
Так что тем, кому DoB нужен прямо сейчас уже могут им пользоваться, все необходимое для этого есть.
Ну а для статического анализа кода инструментов тоже хватает.
Хотя конечно было бы неплохо если бы компилятор был более "разумен" и мог генерировать больше предупреждений о потенциальных ошибках на этапе компиляции. В том числе необходимую информацию компилятор, как я уже раньше писал, мог бы получить из тех же самых пре- и постусловий, и для этого не потребуется расширять язык новыми ключевыми словами.
Re: Adding notnull to the Java Programming Language
От: Аноним  
Дата: 07.08.07 12:57
Оценка: -1
Здравствуйте, Dmytro Sheyko, Вы писали:

DS>Статья:

DS>Adding notnull to the Java Programming Language
Автор(ы): Dmytro Sheyko
Дата: 08.08.2004
В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.


DS>Авторы:

DS> Dmytro Sheyko

DS>Аннотация:

DS>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.

Эта идея полный бред.

Вместо того чтобы нормально проектировать системы, и ответственно подходить к вопросу проверок кода и тп предлагается ввести "чудо" слово, после которого все проблемы разом уйдут. Это не так. Программисты у которых руки растут из невнятных мест, всегда будут писать плохо. Хоть ты трижды напиши notnull.

Потом техническая сторона вопроса смешна.
private notnull String firstName;
уже должен кинуть ошибку так как firstName — null (!!! СЮРПРАЙЗ !!!)
Это значит придется забивать всегда обьект какимто дефолтным значением. И следовательно идея с notnull вообще непонятна зачем, когда можно просто юзать дефолтные значения.

При этом то что указывалось как предпосылка — тоже полный бред.
Если мы можем передать null а потом обьект упадет — значит это должно быть отловлено конструктором. Если это чужая библиотека — соответствующий багрепорт соответствующему создателю кода.

И вообще строго говоря — null значения не на пустом месте появляются. И чаще всего не по вине разработчиков которые не вставили проверку на null, а по вине тех кто вообще не представляет какие процессы идут в их системе.


Сорри что незарганый — потом зарегаюсь и подпишусь уже как следует.

Сергей.
Re[2]: Adding notnull to the Java Programming Language
От: dshe  
Дата: 07.08.07 13:15
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Dmytro Sheyko, Вы писали:


DS>>В данной статье рассматривается расширение языка программирования Java, которое позволяет существенно сократить количество ошибок, связанных с разыменованием нулевого указателя и обычно проявляющихся в виде неожиданного исключения java.lang.NullPointerException.


А>Эта идея полный бред.


Если есть желание это обсудить, предлагаю написать мне в приват. За бурными эмоциями я пока не уловил суть критики.
--
Дмитро
Re[3]: Adding notnull to the Java Programming Language
От: C0s Россия  
Дата: 07.08.07 14:53
Оценка: +1
Здравствуйте, dshe, Вы писали:

А>>Эта идея полный бред.


D>Если есть желание это обсудить, предлагаю написать мне в приват. За бурными эмоциями я пока не уловил суть критики.


в свете того, что здесь совсем недавно уже обсуждались такие решения как OVal, которые уже претворили в некотором виде идею контрактности в жизнь, не очень понятно, зачем обсуждать статью
Re[4]: Adding notnull to the Java Programming Language
От: Blazkowicz Россия  
Дата: 13.08.07 09:18
Оценка:
Здравствуйте, C0s, Вы писали:

C0s>в свете того, что здесь совсем недавно уже обсуждались такие решения как OVal, которые уже претворили в некотором виде идею контрактности в жизнь, не очень понятно, зачем обсуждать статью


Как я понимаю, статья все же про compile time. Что позволяет обнаружить проблему ещё раньше, чем Oval.
Re[2]: Adding notnull to the Java Programming Language
От: Blazkowicz Россия  
Дата: 13.08.07 09:19
Оценка:
Здравствуйте, Аноним, Вы писали:

А>И вообще строго говоря — null значения не на пустом месте появляются. И чаще всего не по вине разработчиков которые не вставили проверку на null, а по вине тех кто вообще не представляет какие процессы идут в их системе.


Видал я проекты заполненые проверками на null. К чему нужны эти тоны лишнего кода, когда их можно смела выкинуть, если убедиться что переменная никогда не станет null.
Re[5]: Adding notnull to the Java Programming Language
От: C0s Россия  
Дата: 13.08.07 09:26
Оценка: 2 (1)
Здравствуйте, Blazkowicz, Вы писали:

C0s>>в свете того, что здесь совсем недавно уже обсуждались такие решения как OVal, которые уже претворили в некотором виде идею контрактности в жизнь, не очень понятно, зачем обсуждать статью


B>Как я понимаю, статья все же про compile time. Что позволяет обнаружить проблему ещё раньше, чем Oval.


я, в большей степени, имел в виду, что констрейнтов в общем случае может быть много одновременно и не только на not-null
гарантия not-null — частный случай программирования-по-контракту и, хотя она даже сама по себе полезна, всё же интереснее обсуждать более общие случаи и подходы

потом, в compile-time много не накопать — обычно алгоритмы характеризуются тем, что работают на значениях, попавших в контекст выполнения алгоритма "извне" (как параметры нескольких вложенных вызовов методов, как параметры инстанцирования классов и т.п.). и компилятору просто невмоготу построить все возможные пути, которые ведут в текущий компилируемый метод, и он в любом случае, получается, должен вставлять runtime-проверки
а пользы, если он начнёт отлавливать 1% случаев, аналогичных по природе Statement is unreachable — ровно на этот 1%. ты вот часто, к примеру, видишь сообщение компилятора statement is unreachable?
Re[3]: Adding notnull to the Java Programming Language
От: C0s Россия  
Дата: 13.08.07 09:31
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Аноним, Вы писали:


А>>И вообще строго говоря — null значения не на пустом месте появляются. И чаще всего не по вине разработчиков которые не вставили проверку на null, а по вине тех кто вообще не представляет какие процессы идут в их системе.


B>Видал я проекты заполненые проверками на null. К чему нужны эти тоны лишнего кода, когда их можно смела выкинуть, если убедиться что переменная никогда не станет null.


смелость — города берёт, но правильный код писать не помогает.
к чему это я? да к тому, что лучше проверок расставить, чем использовать "метод пристального взгляда" для "убеждения, что переменная никогда не станет null". лучше всего — чтобы проверки расставлялись "магическо-автоматическим способом", что, собственно, на аннотациях делается достаточно удобно.
кстати, автор про аннотации справедливо упоминает а лично мне, в конечном итоге, не так важно, кто потом по этим аннотациям генерирует проверки — aop или компилятор. просто в текущей ситуации требовать усложнения компилятора, когда есть уже целый ряд инструментов, решающих задачу, как минимум, достойно принципа "семь раз отмерь". к тому же отдельные инструменты — всегда двигатель прогресса, т.к. присутствует элемент соперничества. а заложить это в компилятор — тогда по полгода придётся ждать добавления поддержки очередного констрейнта и прочих удобств.
Re: notnull не очень хорошая идея
От: Baudolino  
Дата: 13.08.07 10:10
Оценка:
Жаль что JetBrains лезет вперёд батьки и вводит нестандартные конструкции.

На мой взгляд намного полезнее и корректнее было бы ввести систему аннотаций, например, так:
.
Re[6]: Adding notnull to the Java Programming Language
От: Baudolino  
Дата: 13.08.07 11:04
Оценка:
C0s>я, в большей степени, имел в виду, что констрейнтов в общем случае может быть много одновременно и не только на not-null
Золотые слова. Я чуть ниже откомментил правильный на мой взгляд подход.
Re[7]: Adding notnull to the Java Programming Language
От: Baudolino  
Дата: 13.08.07 11:07
Оценка: 6 (1) +1
B>>Всегда ли нам приходится иметь дело с таким хорошим дизайном что в нем не встречаются NPE?
ZEN>Почему NullPointerException не встречается в средах програмирования на Java? Это же целые конгломераты классов и объектов с гибкой системой управления кодом.
Пять копеек. Встречается. Eclipse, исходный код и архитектура которого есть настоящий кошмар.
Re[8]: Adding notnull to the Java Programming Language
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 13.08.07 12:55
Оценка:
Здравствуйте, Baudolino, Вы писали:

B>Пять копеек. Встречается. Eclipse, исходный код и архитектура которого есть настоящий кошмар.

Конкретнее можно? Про исходный код... к примеру, SWT/JFace так попросту напичкан всевозможными NullPointerException, IllegalArgumentException и etc. В особенности интересна претензия к архитектуре Eclipse, это OSGi вам не по душе или что?
Re[2]: notnull не очень хорошая идея
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 13.08.07 12:55
Оценка:
Здравствуйте, Baudolino, Вы писали:

B>Жаль что JetBrains лезет вперёд батьки и вводит нестандартные конструкции.

Есть потребность в контрактном программировании, а JDK на данный момент не предоставляет удобный инструментарий для того (даже контракты на утверждениях assert — это все же жуткий overhead), так что же — ждать у моря погоды?

B>На мой взгляд намного полезнее и корректнее было бы ввести систему аннотаций, например, так:

B>...
Посмотрите Oval, там все это есть. Про java.constraint.Optional не понял, какой смысл в него вкладывается?
Re[4]: Adding notnull to the Java Programming Language
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 13.08.07 12:55
Оценка:
Здравствуйте, C0s, Вы писали:

В принципе, Blazkowicz тоже дело говорит. Далеко не все классы вообще должны бояться пустых параметров, т.е. могут и иметь некоторую семантику обработки null. А также многие классы или уверенно не должны получать null (по логике связи объектов), или же локализация данной ошибки настолько минимальна по времени, что дополнительные проверки только отнимут лишнее время. Все субъективно... но я пока увидел эффективность применения Oval только в BLL-объектах, слишком много зайцев за раз:
Re[9]: Adding notnull to the Java Programming Language
От: Baudolino  
Дата: 13.08.07 15:03
Оценка:
R>Конкретнее можно? Про исходный код... к примеру, SWT/JFace так попросту напичкан всевозможными NullPointerException, IllegalArgumentException и etc.
SWT — отдельный разговор. Я в него не играю с тех пор, как пересел дома на MSVUx64, потому что нет нормальной реализации.

>В особенности интересна претензия к архитектуре Eclipse, это OSGi вам не по душе или что?

RCP с его обилием синглтонов. Внутренние пакеты. Плохо продуманное и часто меняющееся API.

(еще три месяца назад я писал на базе Eclipse RCP коммерческий софт и сейчас радуюсь, что завязал — хоть эта платформа и лучшая)
Re[3]: notnull не очень хорошая идея
От: Baudolino  
Дата: 13.08.07 15:14
Оценка:
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 будет добавлять свой анализ, а библиотеки приложения с аннотированной моделью — расширенную семантику (например с помощью валидаторов для проверки пользовательского ввода).
Re[4]: notnull не очень хорошая идея
От: mkizub Литва http://symade.tigris.org
Дата: 13.08.07 15:30
Оценка:
Здравствуйте, Baudolino, Вы писали:

B>>>Жаль что JetBrains лезет вперёд батьки и вводит нестандартные конструкции.

R>>Есть потребность в контрактном программировании, а JDK на данный момент не предоставляет удобный инструментарий для того (даже контракты на утверждениях assert — это все же жуткий overhead), так что же — ждать у моря погоды?
B>Разумеется нет. Но такой инструментарий должен быть независимым от производителя IDE.

И независимым от языка, потому как ждать у моря погоды тоже хреново. Особенно если у тебя частная задача, и встраивать её в язык программирования будет излишним.
Следовательно, нужен некий стандарт на представление кода, единый для компиляторов и других средств программирования (IDE, верификаторов, генераторов кода и пр.). Можно сделать такой стандарт для явы, но с одной стороны, ява будет развиваться дальше (и стандарт прийдётся менять), а с другой стороны, неплохо бы иметь ту-же функциональность и для других языков — как используемых вместе с java (вроде JSP), так и подобных языков (C#).
Единым стандартом сейчас является текстовое представление кода, которое не отвечает всем вышеупомянутым пожеланиям с одной стороны, а с другой стороны — неудобно для работы (всё равно и компилятор, и IDE, и генераторы кода преобразуют текст в AST — abstract syntax tree).

Таким образом, если мы хотим сделать расширяемое (в будущем и между языками в настоящем) стандартное представление, для анализа кода и прочих средств разработки — лучше отказаться от текстового представления и стандартизировать AST представление. Вот SymADE — это и есть такой проект.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
И опять офф про Eclipse
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 13.08.07 15:49
Оценка:
Здравствуйте, Baudolino, Вы писали:

B>RCP с его обилием синглтонов.

Примеры и предложения по тому, как обойтись без них?

B>Внутренние пакеты. Плохо продуманное и часто меняющееся API.

org.eclipse.*.internal.*?
Если вы о том, то... вы читали рекомендации по тому, что не стоит пользоваться классами данных пакетов?

B>(еще три месяца назад я писал на базе Eclipse RCP коммерческий софт и сейчас радуюсь, что завязал — хоть эта платформа и лучшая)

Согласны, что лучшая платформа, но радуетесь, что завязали — очень непонятно. И какие есть альтернативы?
Re[4]: notnull не очень хорошая идея
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 13.08.07 15:49
Оценка:
Здравствуйте, 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 такого счастья ждать в ближайшие годы, как и у моря погоды.
Re[5]: notnull не очень хорошая идея
От:  
Дата: 13.08.07 16:02
Оценка: +1
Hello, mkizub!
You wrote on Mon, 13 Aug 2007 15:30:26 GMT:

m> Таким образом, если мы хотим сделать расширяемое (в будущем и

m> между языками в настоящем) стандартное представление, для анализа
m> кода и прочих средств разработки — лучше отказаться от текстового
m> представления и стандартизировать AST представление. Вот
m> SymADE — это и есть такой проект.

Максим, ты уже притомил пиаром своего SymADE. Начинает напоминать культ N.
Posted via RSDN NNTP Server 2.1 beta
Re[6]: notnull не очень хорошая идея
От: mkizub Литва http://symade.tigris.org
Дата: 13.08.07 16:18
Оценка: :)
Здравствуйте, YК, Вы писали:

YК>Максим, ты уже притомил пиаром своего SymADE. Начинает напоминать культ N.


То есть, раз ты притомился, мне вообще замолкнуть в тряпочку?
Или пиарить то, что тебя ещё не притомило?
И лучше проконсультироваться с тобой, предварительно, не притомит ли тебя пиар Oval-а или ещё какой хрени, да?
Ты можешь внятно сформулировать, что тебя задело?
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[7]: notnull не очень хорошая идея
От:  
Дата: 13.08.07 16:40
Оценка:
Hello, mkizub!
You wrote on Mon, 13 Aug 2007 16:18:46 GMT:

YК>> Максим, ты уже притомил пиаром своего SymADE. Начинает

YК>> напоминать культ N.

m> То есть, раз ты притомился, мне вообще замолкнуть в тряпочку?

m> Или пиарить то, что тебя ещё не притомило?
m> И лучше проконсультироваться с тобой, предварительно, не притомит
m> ли тебя пиар Oval-а или ещё какой хрени, да?
m> Ты можешь внятно сформулировать, что тебя задело?

Меня ничего не задело. Просто не надо сунуть своего сфероконя в вещи, имеющиие к нему отдаленное отношение.
Posted via RSDN NNTP Server 2.1 beta
Re: И опять офф про Eclipse
От: Baudolino  
Дата: 13.08.07 16:50
Оценка:
Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, Baudolino, Вы писали:


B>>RCP с его обилием синглтонов.

R>Примеры и предложения по тому, как обойтись без них?
Вкратце — IoC. А детально — поля этой книги слишком маленькие.

B>>Внутренние пакеты. Плохо продуманное и часто меняющееся API.

R>org.eclipse.*.internal.*?
R>Если вы о том, то... вы читали рекомендации по тому, что не стоит пользоваться классами данных пакетов?
К сожалению, это не всегда возможно. В деталях, простите, сейчас не могу — конкретные грабли уже успел забыть.

B>>(еще три месяца назад я писал на базе Eclipse RCP коммерческий софт и сейчас радуюсь, что завязал — хоть эта платформа и лучшая)

R>Согласны, что лучшая платформа, но радуетесь, что завязали — очень непонятно. И какие есть альтернативы?
Сменил место работы и теперь ругаюсь на Spring Альтератив пока не вижу. Eclipse хоть и сырая технология, но работающая и позволяющая делать очень многое.
Re[8]: notnull не очень хорошая идея
От: mkizub Литва http://symade.tigris.org
Дата: 13.08.07 16:57
Оценка:
Здравствуйте, YК, Вы писали:

YК>Меня ничего не задело. Просто не надо сунуть своего сфероконя в вещи, имеющиие к нему отдаленное отношение.


Имеющего к этому прямое отношение, потому как решение данной проблемы было одной из основных мотиваций при написании SymADE.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[9]: notnull не очень хорошая идея
От:  
Дата: 13.08.07 17:09
Оценка:
Hello, mkizub!
You wrote on Mon, 13 Aug 2007 16:57:22 GMT:

YК>> Меня ничего не задело. Просто не надо сунуть своего сфероконя в

YК>> вещи, имеющиие к нему отдаленное отношение.

m> Имеющего к этому прямое отношение, потому как решение данной

m> проблемы было одной из основных мотиваций при написании SymADE.

Обобщать на основе мотиваций — это сильно

Языконезависимость для решения данной проблемы — а именно реализации контрактного программирования в Java — нафиг не нужна.
Posted via RSDN NNTP Server 2.1 beta
Re[10]: notnull не очень хорошая идея
От: mkizub Литва http://symade.tigris.org
Дата: 13.08.07 18:54
Оценка:
Здравствуйте, 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 и т.п. И заодно — как их надо продвигать, чтоб они стали мэйнстримом. Так что я пошёл работать, не буду тебя лишний раз раздражать.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[11]: notnull не очень хорошая идея
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 13.08.07 19:23
Оценка:
Здравствуйте, mkizub, Вы писали:

M>ЗЫ Кстати, мне тут мысля пришла в голову, наглядно объясняющая почему SymADE, Nemerle, Scala и иже с ними — не смогут вытеснить C#, Java и т.п. И заодно — как их надо продвигать, чтоб они стали мэйнстримом. Так что я пошёл работать, не буду тебя лишний раз раздражать.

Действительно интересно, почему?
Re[12]: notnull не очень хорошая идея
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 13.08.07 19:28
Оценка:
Здравствуйте, rsn81, Вы писали:

R>Действительно интересно, почему?

А, все, уже прочитал: Грамотное развитие новых языков и средств программирования
Автор: mkizub
Дата: 13.08.07
, эко задвинули!
Re[4]: notnull не очень хорошая идея
От: Blazkowicz Россия  
Дата: 14.08.07 08:20
Оценка:
Здравствуйте, Baudolino, Вы писали:

B>Разумеется нет. Но такой инструментарий должен быть независимым от производителя IDE.

Скажите это тем кто пользуется визуальными редакторами GUI. Которые поризводители IDE штампуют кто во что горазд без какой-либо совместимости.
Re[11]: notnull не очень хорошая идея
От:  
Дата: 14.08.07 08:56
Оценка:
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 упомянуть?
Posted via RSDN NNTP Server 2.1 beta
Re[12]: notnull не очень хорошая идея
От: mkizub Литва http://symade.tigris.org
Дата: 14.08.07 09:23
Оценка:
Здравствуйте, YК, Вы писали:

YК>Там речь идет о проверке компилятором. К контрактному программированию это имеет отношение только тем, что формально выражается предусловие, т.е. контракт. Последующая проверка компилятором — это автоматическое обнаружение ошибок, верификация — называйте как хотите, только это не контрактное программирование. Последнее предполагает знание клиента или поставщика о контракте, и осознанное следование этому контракту.


а) топик о notnull — верификации условия на этапе компиляции или выполнения,
б) про контрактное программирование ты завёл речь, и естественно я решил, что ты этот термин употребляешь не как work-by-contract технику Эйфеля, а в более общем смысле.

Так что выбирай — или твой изначальный заезд с контрактным программированием не в тему, или мы говорим об общем случае контрактов, которые работают и в compile time. Как выберешь — так и продолжим.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[5]: notnull не очень хорошая идея
От: mkizub Литва http://symade.tigris.org
Дата: 14.08.07 09:27
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

>>Разумеется нет. Но такой инструментарий должен быть независимым от производителя IDE.

B>Скажите это тем кто пользуется визуальными редакторами GUI. Которые поризводители IDE штампуют кто во что горазд без какой-либо совместимости.

Наверное под словом "должен" он имел в виду идеальный для пользователя вариант, а не более распространённый — "хотели как лучше, а получилось как всегда".
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[13]: notnull не очень хорошая идея
От:  
Дата: 14.08.07 10:01
Оценка:
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> и продолжим.

Мне выбирать незачем — речь шла о контрактном программировании. Ты бы лучше следил за темой разговора.
Posted via RSDN NNTP Server 2.1 beta
Re[13]: notnull не очень хорошая идея
От: Eugeny__ Украина  
Дата: 14.08.07 10:55
Оценка:
Здравствуйте, mkizub, Вы писали:

M>а) топик о notnull — верификации условия на этапе компиляции или выполнения,




А при чем время выполнения-то? ИМХО, про него речь не шла вообще.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[14]: notnull не очень хорошая идея
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 14.08.07 11:09
Оценка:
Здравствуйте, Eugeny__, Вы писали:

E__>А при чем время выполнения-то? ИМХО, про него речь не шла вообще.

Где-то отсюда Re[3]: Adding notnull to the Java Programming Language
Автор: C0s
Дата: 07.08.07
разговор пошел именно про runtime.
Re[5]: notnull не очень хорошая идея
От: Baudolino  
Дата: 14.08.07 12:34
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>Скажите это тем кто пользуется визуальными редакторами GUI.

Хихи. Я с такими людьми не общаюсь.

>Которые поризводители IDE штампуют кто во что горазд без какой-либо совместимости.

Пороть их надо нещадно за то, что они штампуют
Re[14]: notnull не очень хорошая идея
От: Baudolino  
Дата: 14.08.07 12:48
Оценка:
YК>Есть совершенно четкое определение контрактного программирования, данное Мейером. И именно о контрактном программировании шла речь в этой ветке, а не о верификации notnull.
В этой ветке я изначально ставил вопрос о неполноте решения с notnull. При чём тут "чёткое определение Мейера"?
Re[5]: notnull не очень хорошая идея
От: Baudolino  
Дата: 14.08.07 12:53
Оценка:
M>И независимым от языка, потому как ждать у моря погоды тоже хреново.
Почти так. Для выражения любых мыслей язык всё равно нужен. Другое дело, что он может быть специализированным, как например XMI или OCL. Вообще, подобные механизмы определения контрактов должны разрабатываться с привязкой к MOF. А далее см. Eclipse Modeling Project.
Re[5]: notnull не очень хорошая идея
От: Baudolino  
Дата: 14.08.07 13:05
Оценка:
Здравствуйте, rsn81, Вы писали:

Не успел вчера ответить.

B>>Разумеется нет. Но такой инструментарий должен быть независимым от производителя IDE.

R>А, вы про наработки JetBrains? Не в курсе, как там. Oval же — просто библиотека, правда и требует потрошения кода аспектным компилятором.
Овал почти хорош, да. Кой-чего не хватает (см.ниже).

B>>Декларируется в явном виде возможность не задавать значение поля.

R>Все равно непонятно, чем это отличается от простой декларации переменной...
Возможностью определять семантику определения в runtime (для чего, собственно, и придуманы аннотации).

B>>public class Profile {

B>>@Optional PostalAddress address = new PostalAddress(); // optional = адрес не заполнен, хотя объект под него создан
R>Какую смысловую нагрузку несет @Optional для поля address в классе Profile; то есть Profile знает, что его поле address фиктивно? Допустим... и что дальше, как это есть, чем это лучше null?
Тут можно долго фантазировать на самом деле Предлагаю ограничиться следующим: Optional я упомянул для симметрии определению Mandatory. Конкретная реализация валидатора может доопределить семантику в runtime.

R>Что-то мне подсказывает, что от JCP такого счастья ждать в ближайшие годы, как и у моря погоды.

Hibernate привел к появлению JPA. Независимая сторонняя библиотека может сделать то же самое. Какой она должна быть?
1. Аннотации декларируют ограничения. Исчерпывающий набор базовых аннотаций (поддержка OCL) плюс возможность определения пользовательских.
2. API для валидации. Пользователь может расширять базовую семантику в своих валидаторах по принципу:
ChildValidator.isValid(object) => BaseValidator.isValid(object)

3. Полноценная поддержка AOP. Хочется определять необходимость валидации для любых методов (в Oval не увидел), например так:
@Valid 
public Result execute(@Valid Scenario scenario) {
    // сюда мы попадаем только в случае, если объект scenario прошёл валидацию без ошибок
    ...
    return result; // значение будет возвращено только в случае, если оно корректно
}
Re[6]: notnull не очень хорошая идея
От: C0s Россия  
Дата: 14.08.07 14:10
Оценка:
Здравствуйте, Baudolino, Вы писали:

B>3. Полноценная поддержка AOP. Хочется определять необходимость валидации для любых методов (в Oval не увидел), например так:


не знаю, правильно ли я понимаю, что ты имеешь в виду, но в OVal это есть
Re[6]: notnull не очень хорошая идея
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 14.08.07 15:57
Оценка: 1 (1) +1
Здравствуйте, Baudolino, Вы писали:

B>Не успел вчера ответить.



B>Овал почти хорош, да. Кой-чего не хватает (см.ниже).

Прочитал, говорю сразу — неправда, практически все это есть.

B>Возможностью определять семантику определения в runtime (для чего, собственно, и придуманы аннотации).

Смотрели @Assert (+Groovy) в OVal-е?
И потом, во-первых, мне сложно представить контракты, которые нужно генерировать рефлексией, а во-вторых, надеюсь, мне не наврали (сам не сталкивался, но заинтересовался), что аспектный компилятор можно каким-то образом встроить в runtime, то есть все, что нужно вам — есть: рефлексия, на основе которой вы создаете свои гиперсложные-изменчивые контракты, и некий АОП-JIT, их компилирующий-исполняющий.

B>Тут можно долго фантазировать на самом деле Предлагаю ограничиться следующим: Optional я упомянул для симметрии определению Mandatory. Конкретная реализация валидатора может доопределить семантику в runtime.

Не знаю, честно говоря, так и не понял, о чем речь.

B>1. Аннотации декларируют ограничения. Исчерпывающий набор базовых аннотаций (поддержка OCL) плюс возможность определения пользовательских.

Есть.

B>2. API для валидации. Пользователь может расширять базовую семантику в своих валидаторах по принципу:

B>
B>ChildValidator.isValid(object) => BaseValidator.isValid(object)
B>

Есть. Практически дословно.

B>3. Полноценная поддержка AOP. Хочется определять необходимость валидации для любых методов (в Oval не увидел), например так:

B>
B>@Valid 
B>public Result execute(@Valid Scenario scenario) {
B>    // сюда мы попадаем только в случае, если объект scenario прошёл валидацию без ошибок
B>    ...
B>    return result; // значение будет возвращено только в случае, если оно корректно
B>}
B>

Вроде тоже есть, конкретно, что не смогли?
Re[7]: notnull не очень хорошая идея
От: Baudolino  
Дата: 15.08.07 09:12
Оценка:
Здравствуйте, rsn81, Вы писали:

R>Вроде тоже есть, конкретно, что не смогли?

Я смотрел только страницу http://oval.sourceforge.net — на знакомство с исходниками нет времени. Если вы имеете в виду probe mode, то я не об этом. Код приведённый на странице выглядит просто жутко. Я имею в виду буквально следующее:


@Constraints({@OCL("name.length > age")})
public class Entity {
   @Max(10)
   int age;

   @MaxLength(20) 
   String name;
}

public class EntityDAO {
   
   public void save(@Valid Entity entity) throws ValidationFailedException {
      // при вызове этого метода происходит валидация параметра entity по всем наложенным ограничениям
   }

}

Oval такое поддерживает или нужно всегда использовать probe mode (в котором, как я понял из кода, происходит перехват сеттеров — а как же тогда валидация на сложных ограничениях)?

P.S. NP, я вообще использую для таких вещей фреймворк собственной разработки, в котором как раз собираюсь реализовать описанное
Re[8]: notnull не очень хорошая идея
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 15.08.07 10:32
Оценка:
Здравствуйте, Baudolino, Вы писали:

B>Oval такое поддерживает или нужно всегда использовать probe mode (в котором, как я понял из кода, происходит перехват сеттеров — а как же тогда валидация на сложных ограничениях)?

Using the probe mode to simplify UI user input validation — вроде бы меня устраивает вполне. Если, как вы говорите, вас такой вариант не устраивает, можно посмотреть в сторону @ValidateWithMethod и @CheckWith: Expressing complex class specific constraints

B>P.S. NP, я вообще использую для таких вещей фреймворк собственной разработки, в котором как раз собираюсь реализовать описанное

В "обычных" классах все еще пользуюсь для этого assert-ами, а OVal использую только для контрактного программирования в BLL(+GUI) и DAL(+DB). Ради одного только NullPointerException усложнять обычную библиотеку OVal-ом, который зовет с собой в гости АОП-компилятор — по-моему, не очень дальновидно.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.