Пришла тут в голову забавная на мой взгляд идея. Берём динамически типизированный язык вроде жаваскрипта. Пишем код. Пишем тесты. Прогоняем тесты. И вот тут запоминаются все типы, которые приходили и уходили в функцию. После этого функцию нельзя вызывать с другими типами. Будет ошибка компиляции.
Я немного сумбурно это расписал, но постарался выразить главную идею. Типы объявляются опосредованно, через тесты.
Здравствуйте, νsb, Вы писали:
νsb>Пришла тут в голову забавная на мой взгляд идея. Берём динамически типизированный язык вроде жаваскрипта. Пишем код. Пишем тесты. Прогоняем тесты. И вот тут запоминаются все типы, которые приходили и уходили в функцию. После этого функцию нельзя вызывать с другими типами. Будет ошибка компиляции.
νsb>Я немного сумбурно это расписал, но постарался выразить главную идею. Типы объявляются опосредованно, через тесты.
νsb>Как вам такая идея — взлетит?
Ранее мы упоминали, что clojure.spec.test.alpha
предоставляет инструменты для автоматического тестирования функций.
Когда у функций есть спецификации, мы можем использовать проверку,
чтобы автоматически генерировать тесты, которые проверяют функцию
с использованием спецификаций.
Здравствуйте, Эйнсток Файр, Вы писали:
R>> Адепты доказательного программирования — это типа вот эти ребята, которые не осилили тесты писать?
ЭФ>Разные. Но поскольку расстреливать вы собрались всех, то начнём это делать с проповедников тестирования.
О, наверно просто контекста не хватило. Я против тех, кто не пишет тесты, прикрываясь теорией. Если кто-то вместо "иди в жопу со своим тестированием" скажет: "иди в жопу со своим тестированием, я сейчас всё на типах выведу" — я только за. Обычно против тестов гонят убогие, которые просто не осилили.
Здравствуйте, νsb, Вы писали:
νsb>Пришла тут в голову забавная на мой взгляд идея. Берём динамически типизированный язык вроде жаваскрипта. Пишем код. Пишем тесты. Прогоняем тесты. И вот тут запоминаются все типы, которые приходили и уходили в функцию. После этого функцию нельзя вызывать с другими типами. Будет ошибка компиляции.
Так функция и не вызовется с другими типами, если код не менять.
А если код менять, то и типы могут поменяться, и предыдущие типы нам не важны.
Ну и непонятно, что дальше-то что с этими типами делать, какая задача решалась?
Похожий подход используется в тестировании — сравнение результатов предыдущих и последующих запусков (канонизация тестов, сравнение скриншотов).
Здравствуйте, Буравчик, Вы писали:
Б>Так функция и не вызовется с другими типами, если код не менять.
Не понял. У нас типы выводятся в момент компиляции файла.
Грубо говоря у нас есть файл, в нём код и в нём же тесты. Мы сначала запускаем интерпретатор, который игнорирует типы. Этот интерпретатор прогоняет все тесты в этом файле и во время каждого вызова функции запоминает типы значений, которые эта функция принимала и возвращала. А также, видимо, типы переменных.
Эта запомненная информация где-то сохраняется и представляет из себя типизированную сигнатуру функции.
Простой пример:
function f(n) {
let result;
if (n == 0) {
result = 1n;
} else {
const f1 = f(n - 1);
result = BigInt(n) * f1;
}
return result;
}
tests {
assert(f(0) == 1);
assert(f(3) == 6);
}
Тут мы прогнав тесты видим, что функция вызывается с параметром типа number и возвращает BigInt при всех выполнениях. То бишь после выполнения куда-то записывается что-то вроде
function f(n: number): BigInt {
let result: BigInt;
if (n == 0) {
result = 1n;
} else {
const f1: BigInt = f(n - 1);
result = BigInt(n) * f1;
}
return result;
}
и теперь её из другого файла нельзя будет вызвать со строкой или null-ом, будет ошибка компиляции.
Наверное можно даже не просто number выводить, а что-то вроде uint8. Или вообще конкретный тип, от 0 до 3 в данном примере. Типа нужен факториал со значениями побольше — пиши тесты на значения побольше.
Б>Ну и непонятно, что дальше-то что с этими типами делать, какая задача решалась?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Тебе надо мотивацию выписать. ЭФ>Зачем это нужно, и какие преимущества даст.
ЭФ>Программного кода придётся писать больше, ЭФ>потому что размер тестов больше, чем размер указания типа. ЭФ>И это плохо. Чем-то это должно компенсироваться.
ЭФ>Чем же?
Тесты писать всё равно надо. Поэтому в данном случае это влияния не имеет.
Чем хорошо: меньше писанины. А также для уточнения типов придётся писать больше тестов, эдакая мотивация программистам писать тесты на все возможные значения на входе и на выходе.
Чем плохо — пока не знаю. Есть вероятность, что тестов придётся писать слишком много.
Если тесты недетерминированные, то будут недетерминированные типы. Но в принципе это в любом случае нехорошо. Плюс можно тесты сделать детерминированными, убрав любые источники случайности.
?sb>Чем плохо — пока не знаю. Есть вероятность, что тестов придётся писать слишком много.
Например тем, что пока всё тестами не покроешь написанное тупо запустить не получится.
Кстати а сами тесты как будут определять что в них куда передавать можно? Курица и йайцо вырисовывается.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>?sb>Чем плохо — пока не знаю. Есть вероятность, что тестов придётся писать слишком много. CC>Например тем, что пока всё тестами не покроешь написанное тупо запустить не получится.
Ну и хорошо, test driven development и всё такое.
Не, можно сделать опцию запуска с отключенной проверкой типов, раз она для тестов в любом случае будет, для дебага тоже может пригодиться.
CC>Кстати а сами тесты как будут определять что в них куда передавать можно? Курица и йайцо вырисовывается.
Тесты будут синтаксически встроены в язык и в них будет отключена проверка типов.
