Посмотрел реализацию по вашей наводке. Вы очень полезны для проекта :)
«Code Contracts» нельзя задать для чисто виртуальных методов, т.к. у них нет тела. В моем случае ограничения задаются отдельно от тела.
Синтаксис «Code Contracts» отвратителен — но это дело вкуса.
Посмотрел, спасибо за ссылку. Я не уверен, что надо добавлять в язык программирования математические символы. Смешивать процедурный язык с функциональным — может оказаться очень болезненно.
К сожалению, местная школота увидев что-то умное, на английском и не про котиков заминусовала мне карму и я не смогу опубликовать более подробную статью.
1) ООП делает код более структурированным, у этого есть отдельные плюшки, которые просто не раскрыты в видео. Обычные функции разрешены.
2) Вы либо плохо смотрели видео, либо плохо владеете английским: был создан один файл и на экране лишь два представления этого файла. Представления таки нужны, ибо это удобно — скрыть реализацию класса одним щелчком.
Вы правы, у меня к сожалению не хватает времени на эти проекты.
Знаете ли, кушать хочется, и работаю фулл-тайм на одного работодателя :)
И личная жизнь у меня таки есть :)))
Иногда бывают перерывы между проектами, и могу заниматься своими, но не так быстро как хотелось бы.
Не удивительно, что у вас возникли ассоциации с Delphi.
Рисование окон есть во многих средах, и это удобно. Зачем же портить технику?
Я лишь сделал это еще более удобно за счет того, что отказался от текстовых файлов для исходного кода.
Облегчение программирования за счет этой самой интеграции объектов.
Все языки 4-го поколения (С++, Python и т.д.) предполагают, что их исходный код — текстовые файлы.
Существующие языка 5-го поколения — графические (BPML и т.д.).
Я предлагаю сделать микс: текст + картинки где это удобно.
И главная цель — программист должен как можно меньше думать о специфике языка, код должен быть компактным.
Это такой формат. Вы ведь прочитали всю статью, и прекрасно поняли, что USDS действительно может заменить XML. Вы также прочитали цели публикации. Не пойму, причем здесь юмор?
У вас все еще нет обработки ошибок, юнит-тестов, работы с BigEndian.
А если вы возьмете тот же Protobuf, то все вопросы будут решены бустрее чем за 1 вечер.
Возьмем вот этот метод: Package.WriteString(«SVO»);
Это либо стандартная библиотека какого-то языка, что мешает парсить докумнет на других языках, либо ваша самописная, которая не входит в срок 1 вечер.
Отслеживание трафика профайлером, редактирование конфигов в формате USDS, СУБД может передавать вам результаты SQL запросов в формате USDS: в начале документа схема, далее тонны данных (я плакал глядя на исходный код ODBC-драйвера).
У USDS есть и режим полной бинарности, когда вы не светите схему никому, и везде используются предварительно скомпилированные парсеры (как в protobuf, Bond и т.д.).
Тогда это похоже на решение protobuf с динамическими схемами, которое было описано выше в каментах. Решение в Bond даже лучше, чем у протобуфа, т.к. является частью стандарта.
В USDS второй стороне будет проще, т.к. парсер сам найдет схему данных в бинарном докуенте (при условии что ее туда вообще положили).
«Code Contracts» нельзя задать для чисто виртуальных методов, т.к. у них нет тела. В моем случае ограничения задаются отдельно от тела.
Синтаксис «Code Contracts» отвратителен — но это дело вкуса.
http://www.it-dc.org/projects/g5#TOC-Restrictions
http://www.it-dc.org/projects/g5
http://www.it-dc.org/projects/g5
Замечания принимаются :)
2) Вы либо плохо смотрели видео, либо плохо владеете английским: был создан один файл и на экране лишь два представления этого файла. Представления таки нужны, ибо это удобно — скрыть реализацию класса одним щелчком.
Знаете ли, кушать хочется, и работаю фулл-тайм на одного работодателя :)
И личная жизнь у меня таки есть :)))
Иногда бывают перерывы между проектами, и могу заниматься своими, но не так быстро как хотелось бы.
Рисование окон есть во многих средах, и это удобно. Зачем же портить технику?
Я лишь сделал это еще более удобно за счет того, что отказался от текстовых файлов для исходного кода.
Все языки 4-го поколения (С++, Python и т.д.) предполагают, что их исходный код — текстовые файлы.
Существующие языка 5-го поколения — графические (BPML и т.д.).
Я предлагаю сделать микс: текст + картинки где это удобно.
И главная цель — программист должен как можно меньше думать о специфике языка, код должен быть компактным.
А если вы возьмете тот же Protobuf, то все вопросы будут решены бустрее чем за 1 вечер.
Package.WriteString(«SVO»);
Это либо стандартная библиотека какого-то языка, что мешает парсить докумнет на других языках, либо ваша самописная, которая не входит в срок 1 вечер.
У USDS есть и режим полной бинарности, когда вы не светите схему никому, и везде используются предварительно скомпилированные парсеры (как в protobuf, Bond и т.д.).
В USDS второй стороне будет проще, т.к. парсер сам найдет схему данных в бинарном докуенте (при условии что ее туда вообще положили).