История изменений
Исправление www_linux_org_ru, (текущая версия) :
Ключевое тут то, что библиотека виджета гарантировано присутствует на дисплее.
это да
Но ты не прав, связывая эту потенциальную фичу с конфигом. ... мы можем просто передать туда сообщение CreateWindow с нужным типом виджета и получить хэндлер на окно, вся логика которого сидит на другой стороне.
нет, я прав в том, что акцентирую внимание на связь этой фичи именно с конфигом
разница «бинарного конфига» с бинарным сериализованным сообщением CreateWindow лежит не в принципиальной плоскости, а в плоскости удобства разработки, валидации и верификации
т.е. в *принципе*, я могу обозвать твое сообщение CreateWindow маленьким бинарным конфигом, и ты хрен меня оспоришь — но смысл бинарного конфига, конечно, совсем не в этом
смысл вот в чем:
1. на практике окна (даже формочки) весьма статичны, т.е. вместо цепочки CreateWindow гораздо удобнее конфиг
2. нестатичность форм обычно лежит во вполне определенной плоскости, которую можно и нужно учесть в бинарном конфиге:
Вести лог: [х]
Файл лога: [ /home/user/my_log.log ]
(т.е. если убрать флажок, пропадает целая строчка, а если флажок поставить, то она появляется)
3. контекстные меню тоже весьма статичны, появление в них динамических пунктов, конечно, нужно, но сами эти пункты занимают небольшой процент об общего количества (например «Search google for „тот текст, что был выделен в момент вызова меню”»)
4. бинарный конфиг можно редактировать вне приложения — можно заменить:
Description1: value1
Description2: value2
Description3: value3
на
Description1 Description2 Description3
value1 value2 value3
5. бинарный конфиг удобно переводить
6. бинарный конфиг можно валидировать/верифицировать, т.е. скажем не пропустить
<table columns=2 rows=2><td>a</td><td>b</td><td>c</td><td>c</td><td>бугага</td></table>
на этапе сборки/пакетирования аппликухи (естественно, синтаксис html/xml — это говно; я использую его только для иллюстрации идеи)
и даже если я чего-то забыл — популяность html это именно популярность конфига (хотя и не бинарного); то, что сейчас к хтмл прикрутили всякие операции с DOM еще не служит доказательством, что эти операции в правильно спроектированном хтмл часто нужны, а скорее служит доказательством того, что в хтмл нет много чего
з.ы. но вот можно ли сказать «CreateWindow не нужно»? я не уверен
Исправление www_linux_org_ru, :
Ключевое тут то, что библиотека виджета гарантировано присутствует на дисплее.
это да
Но ты не прав, связывая эту потенциальную фичу с конфигом. ... мы можем просто передать туда сообщение CreateWindow с нужным типом виджета и получить хэндлер на окно, вся логика которого сидит на другой стороне.
нет, я прав в том, что акцентирую внимание на связь этой фичи именно с конфигом
разница «бинарного конфига» с бинарным сериализованным сообщением CreateWindow лежит не в принципиальной плоскости, а в плоскости удобства разработки, валидации и верификации
т.е. в *принципе*, я могу обозвать твое сообщение CreateWindow маленьким бинарным конфигом, и ты хрен меня оспоришь — но смысл бинарного конфига, конечно, совсем не в этом
смысл вот в чем:
1. на практике окна (даже формочки) весьма статичны, т.е. вместо цепочки CreateWindow гораздо удобнее конфиг
2. нестатичность форм обычно лежит во вполне определенной плоскости, которую можно и нужно учесть в бинарном конфиге:
Вести лог: [х]
Файл лога: [ /home/user/my_log.log ]
(т.е. если убрать флажок, пропадает целая строчка, а если флажок поставить, то она появляется)
3. контекстные меню тоже весьма статичны, появление в них динамических пунктов, конечно, нужно, но сами эти пункты занимают небольшой процент об общего количества (например «Search google for „тот текст, что был выделен в момент вызова меню”»)
4. бинарный конфиг можно редактировать вне приложения — можно заменить:
Description1: value1
Description2: value2
Description3: value3
на
Description1 Description2 Description3
value1 value2 value3
5. бинарный конфиг удобно переводить
6. бинарный конфиг можно валидировать/верифицировать, т.е. скажем не пропустить
<table columns=2 rows=2><td>a</td><td>b</td><td>c</td><td>c</td><td>бугага</td></table>
на этапе сборки/пакетирования аппликухи (естественно, синтаксис html/xml — это говно; я использую его только для иллюстрации идеи)
и даже если я чего-то забыл — популяность html это именно популярность конфига (хотя и не бинарного); то, что сейчас к хтмл прикрутили всякие операции с DOM еще не служит доказательством, что эти операции в правильно спроектированном хтмл часто нужны, а скорее служит доказательством того, что в хтмл нет много чего
Исходная версия www_linux_org_ru, :
Ключевое тут то, что библиотека виджета гарантировано присутствует на дисплее.
это да
Но ты не прав, связывая эту потенциальную фичу с конфигом. ... мы можем просто передать туда сообщение CreateWindow с нужным типом виджета и получить хэндлер на окно, вся логика которого сидит на другой стороне.
нет, я прав в том, что акцентирую внимание на связь этой фичи именно с конфигом
разница «бинарного конфига» с бинарным сериализованным сообщением CreateWindow лежит не в принципиальной плоскости, а в плоскости удобства разработки, валидации и верификации
т.е. в *принципе*, я могу обозвать твое сообщение CreateWindow маленьким бинарным конфигом, и ты хрен меня оспоришь — но смысл бинарного конфига, конечно, совсем не в этом
смысл вот в чем:
1. на практике окна (даже формочки) весьма статичны, т.е. вместо цепочки CreateWindow гораздо удобнее конфиг
2. нестатичность форм обычно лежит во вполне определенной плоскости, которую можно и нужно учесть в бинарном конфиге:
Вести лог: [х]
Файл лога: [ /home/user/my_log.log ]
(т.е. если убрать флажок, пропадает целая строчка, а если флажок поставить, то она появляется)
3. контекстные меню тоже весьма статичны, появление в них динамических пунктов, конечно, нужно, но сами эти пункты занимают небольшой процент об общего количества (например Search google for «тот текст, что был выделен в момент вызова меню»)
4. бинарный конфиг можно редактировать вне приложения — можно заменить:
Description1: value1
Description2: value2
Description3: value3
на
Description1 Description2 Description3
value1 value2 value3
5. бинарный конфиг удобно переводить
6. бинарный конфиг можно валидировать/верифицировать, т.е. скажем не пропустить
<table columns=2 rows=2><td>a</td><td>b</td><td>c</td><td>c</td><td>бугага</td></table>
на этапе сборки/пакетирования аппликухи (естественно, синтаксис html/xml — это говно; я использую его только для иллюстрации идеи)
и даже если я чего-то забыл — популяность html это именно популярность конфига (хотя и не бинарного); то, что сейчас к хтмл прикрутили всякие операции с DOM еще не служит доказательством, что эти операции в правильно спроектированном хтмл часто нужны, а скорее служит доказательством того, что в хтмл нет много чего