Общепринятого перевода на русский понятия «typestate» я так и не нашел, поэтому буду называть это «состояния типов». Суть этой фичи в том, что кроме обычного контроля типов, принятого в статической типизации, возможны дополнительные контекстные проверки на этапе компиляции.
В том или ином виде состояния типов знакомы всем программистам — по сообщениям компилятора «переменная используется без инициализации». Компилятор определяет места, где переменная, в которую ни разу не было записи, используется для чтения, и выдает предупреждение. В более общем виде эта идея выглядит так: у каждого объекта есть набор состояний, которые он может принимать. В каждом состоянии для этого объекта определены допустимые и недопустимые операции. И компилятор может выполнять проверки — допустима ли конкретная операция над объектом в том или ином месте программы. Важно, что эти проверки выполняются на этапе компиляции.
Например, если у нас есть объект типа «файл», то у него может быть состояние «закрыт» и «открыт». И операция чтения из файла недопустима, если файл закрыт. В современных языках обычно функция чтения или бросает исключение, или возвращает код ошибки. Система состояний типов могла бы выявить такую ошибку на этапе компиляции — подобно тому, как компилятор определяет, что операция чтения переменной происходит до любой возможной операции записи, он мог бы определить, что метод «Read», допустимый в состоянии «файл открыт», вызывается до метода «Open», переводящего объект в это состояние.
Здравствуйте, Аноним, Вы писали:
А>Например, если у нас есть объект типа «файл», то у него может быть состояние «закрыт» и «открыт». И операция чтения из файла недопустима, если файл закрыт. В современных языках обычно функция чтения или бросает исключение, или возвращает код ошибки. Система состояний типов могла бы выявить такую ошибку на этапе компиляции — подобно тому, как компилятор определяет, что операция чтения переменной происходит до любой возможной операции записи, он мог бы определить, что метод «Read», допустимый в состоянии «файл открыт», вызывается до метода «Open», переводящего объект в это состояние.
Как конкретно система типов может отследить такую ошибку?
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, Аноним, Вы писали:
А>>Например, если у нас есть объект типа «файл», то у него может быть состояние «закрыт» и «открыт». И операция чтения из файла недопустима, если файл закрыт. В современных языках обычно функция чтения или бросает исключение, или возвращает код ошибки. Система состояний типов могла бы выявить такую ошибку на этапе компиляции — подобно тому, как компилятор определяет, что операция чтения переменной происходит до любой возможной операции записи, он мог бы определить, что метод «Read», допустимый в состоянии «файл открыт», вызывается до метода «Open», переводящего объект в это состояние.
J>Как конкретно система типов может отследить такую ошибку?
J>ЗЫ если кто не понял, аноним процитировал часть статьи на хабре http://habrahabr.ru/blogs/programming/135712/#comments
Прикольно. Возможно так же как присвоение не инициализированной переменной?
Чем отличается работа с неоткрытым файлом от работы с неинициализированной переменной?
Вообще походу через лет 10 при компиляции будет проверятся раз в 10 больше чем сейчас и вообще, если программа с компилировалась и не имеет логических ошибок, то она работает и нефиг ее даже тестировать
Здравствуйте, <Аноним>, Вы писали:
А>Typestate
И?
Будет ли это в немерле? В первой версии точно не будет.
Во второй будет все, что пожелаешь, ибо это будет конструктор языков.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, <Аноним>, Вы писали:
А>Вообще походу через лет 10 при компиляции будет проверятся раз в 10 больше чем сейчас и вообще, если программа с компилировалась и не имеет логических ошибок, то она работает и нефиг ее даже тестировать
Я думаю что раньше.
А если учесть что все будет на ДСЛ с предметно ориентированными систематик типов.
Но уйти от тестов не получится.
Просто нужно понимать, что типы и тесты выполняют совершенно разные функции.
Типы ловят нарушение контрактов.
Тесты ловят изменение поведения (регрессии). Те тесты бывают только регрессионными. Других тестов нет и быть не может. Просто по тому, что тесты ничего больше не умеют.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Типы ловят нарушение контрактов.
Вот кстати отличный пример того что ловят типы. Тестами это не поймать. http://rsdn.ru/forum/cpp/4159620.1.aspx
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, <Аноним>, Вы писали:
А>>Typestate WH>И? WH>Будет ли это в немерле? В первой версии точно не будет. WH>Во второй будет все, что пожелаешь, ибо это будет конструктор языков.
Здравствуйте, Аноним, Вы писали:
А>Прикольно. Возможно так же как присвоение не инициализированной переменной? А>Чем отличается работа с неоткрытым файлом от работы с неинициализированной переменной?
с _еще_ не открытым файлом?? Ничем — потому что это оно и тоже, открытие файла — это и есть инициализация переменной
def fileStream = File.Open("file.dat");
а вот как на этапе компиляции запретить обращаться к переменной file после вызова file.Close() — мне не ясно.
def fileStream = File.Open("file.dat");
MySuperMethod(fileStream)
fileStream.Close();
Причем компилятор должен быть достаточно умным, чтоб запретить методу MySuperMethod сохранять fileStream в поле объекта, который будет жить, дольше чем выполняется метод MySuperMethod. Инче этот объект сможеть писать после закрытия файла. Так это должно работать?? Что то сомневаюсь. А как тогда??
Здравствуйте, Jack128, Вы писали:
J>а вот как на этапе компиляции запретить обращаться к переменной file после вызова file.Close() — мне не ясно. J>def fileStream = File.Open("file.dat"); J>MySuperMethod(fileStream) J>fileStream.Close();
J>Причем компилятор должен быть достаточно умным, чтоб запретить методу MySuperMethod сохранять fileStream в поле объекта, который будет жить, дольше чем выполняется метод MySuperMethod. Инче этот объект сможеть писать после закрытия файла. Так это должно работать?? Что то сомневаюсь. А как тогда??
Здравствуйте, Jack128, Вы писали:
J>Что то не догнал, уникальность — это свойство типа или ссылки на конкретный экземпляр типа??
В языках которые их поддерживают, компилятор гарантирует существование только одной ссылки на каждый объект такого типа. Если ссылку куда-то передать, то она выходит из зоны видимости.
Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, Jack128, Вы писали:
J>>Что то не догнал, уникальность — это свойство типа или ссылки на конкретный экземпляр типа??
DR>В языках которые их поддерживают, компилятор гарантирует существование только одной ссылки на каждый объект такого типа. Если ссылку куда-то передать, то она выходит из зоны видимости.
ОК, допустим есть у нас этот уникальный тип File. Как тогда реализовать сценарий, когда туча разного кода пишет в один файл, ну например логи?
Здравствуйте, Jack128, Вы писали:
J>ОК, допустим есть у нас этот уникальный тип File. Как тогда реализовать сценарий, когда туча разного кода пишет в один файл, ну например логи?
Одной функцией логирования, которая запишет логи переданные ей из всех тех различных источников. Хранить много ссылок на один открытый файл и синтактически гарантировать, чтобы им не пользовались после закрытия было бы затруднительно, но с уникальной ссылкой это естественно и интуитивно.
Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, Jack128, Вы писали:
J>>ОК, допустим есть у нас этот уникальный тип File. Как тогда реализовать сценарий, когда туча разного кода пишет в один файл, ну например логи?
DR>Одной функцией логирования, которая запишет логи переданные ей из всех тех различных источников.
А как эта функция должна выглядеть?? Естественно считаем, что она не должна каждый раз открывать/закрывать файл для записи.
Здравствуйте, Jack128, Вы писали:
J>А как эта функция должна выглядеть?? Естественно считаем, что она не должна каждый раз открывать/закрывать файл для записи.
С реактивным программированием она выглядела бы как-то так:
WriteLogs(logs : IObservable[string]) : void
{
unique file = File.OpenText(path);
logs.ForEach(file.WriteLine);
// здесь file уже не доступен и автоматически закрывается
}
Ce n'est que pour vous dire ce que je vous dis.
Re: rust
От:
Аноним
Дата:
07.01.12 01:40
Оценка:
Здравствуйте, Аноним, Вы писали:
Фигня это все, пример с файлами — это всего лишь частный случай проблемы обеспечения инварианта объекта, которая, как ни странно, является прямым следствием самой императивной природы объектно-ориентированного программирования и решается в самом общем случае лишь динамической верификацией, а ограниченно — статическим анализом.
