Можно ли как-то проверять не только соответствие типов атрибутов, но саму структуру Json объекта согласно схеме? Т е осуществлять проверку жесткого соответствия схеме.Например, если в Json объекте появился лишний атрибут, то тест на соответствие созданной ранее схеме завалится? Проверку типов я уже осуществил (java+json-validator+junit), но саму структуру проверить не могу.
Спасибо за развернутый ответ, я Вас понял. По поводу передачи наследников — безусловно, но чтобы работать с конкретным ожидаемым типом надо делать приведение типа и хотелось, чтобы это делал компилятор. Понятно, что при этом нарушается типобезопасность и, признаться, даже не знаю, что лучше, делать as или пользоваться такими костылями, как ковариантность в параметре.
А не могли Вы меня просветить, в языках с более «слабой» типобезопасностью ко- и контр-вариантность реализованы повсеместно?
Да, вы правильно поняли, но вообще говоря, это ограничение компилятора, если бы шарп поддерживал полномасштабную вариантность, можно было бы в качестве аргумента задать out-параметр. У Липперта, кажется, был пост, почему c# team сделали именно так, но, увы, я его потерял, возможно, вы поясните. В любом случае, когда я впервые столкнулся с in/out-параметры, я был уверен, что их можно использовать повсеместно и с помощью ключевых слов лишь делать «подсказки» разработчикам и компилятору, но увы :)
Пардон, несколько неправильно скопировал код, в реализации метод принимает BinomTaskData, конечно же. Такая хотелка, но сделать так у меня не получилось, пришлось выделывать костыли
public interface ISolver<out TInputData,out TAnswerData>
{
TAnswerData Solve(TInputData data);
}
И вот в таком виде он не скомпилируется, потому что компилятор ожидает контравариантный параметр. А хочу я очень простого — передавать наследников в качестве аргумента метода Solve, например, я хотел бы сделать такую реализацию:
public class BinomSolver : ISolver<BinomTaskData,BinomAnswerData>
{
public override BinomAnswerData Solve(SolverDataBase input)
{
var data = GetParameter(input);
var discrim = Math.Pow(data.B, 2) - 4 * data.A * data.C;
var x1 = (-data.B + Math.Sqrt(discrim)) / (2 * data.A);
var x2 = (-data.B - Math.Sqrt(discrim)) / (2 * data.A);
return new BinomAnswerData(x1, x2);
}
}
Простите, я правильно понимаю, что в теории любой тип в любом месте может ко/контр/ин-вариантен, но на практике конкретные языки и конкретные компиляторы накладывают ограничения? В своем проекте очень остро столкнулся с проблемой того, что аргументы методов в c# могут быть только контрвариантны
Крест смотрится не очень приятно, особенно из окна аудитории, такое ощущение что рядом с институтом братская могила. Тем более МИФИ учатся представители разных религий и иметь православный крест перед входом (который еще и направлен не в том направлении) не очень хорошее решение. А вот кафедра теологии это уже перебор.
сможет без проблем, но на счет удобства, это индивидуальные качества. Буквально через пару месяцев pocketbook выпустят 10 дюймовое устройство, на нем действительно будет удобно читать djvu и PDF.
Такое ощущение, что автор не держал в руках книгу. Сам являюсь счастливым обладателем сего девайса, и считаю что пластиковая крышка очень нужна, без нее бы у меня экран был бы уже мертв. А то что советуете носить в чехле без крышки, то уже известны случаи, когда ломали экран в этом чехле.
Тоже хотел ее посоветовать, но добрые люди сделали это за меня.
Могу только добавить, что если у вас стоит джейлбрейк, то книги в нее можно заливать с компьютера, что очень удобно, если нет wi-fi.
А не могли Вы меня просветить, в языках с более «слабой» типобезопасностью ко- и контр-вариантность реализованы повсеместно?
И вот в таком виде он не скомпилируется, потому что компилятор ожидает контравариантный параметр. А хочу я очень простого — передавать наследников в качестве аргумента метода Solve, например, я хотел бы сделать такую реализацию:
тема в форуме с комментариями разработчиков.
Могу только добавить, что если у вас стоит джейлбрейк, то книги в нее можно заливать с компьютера, что очень удобно, если нет wi-fi.