лучший способ обработки свойств только для чтения/записи в скриптовом браузерном плагине

Написание встраиваемого кросс-браузерного плагина, который можно использовать в сценариях через JavaScript, я не уверен, как лучше всего обрабатывать свойства только для чтения и только для записи.

Является ли более распространенным или интуитивно понятным

  • молча отбрасывать значения при записи только для чтения и
  • вернуть фиктивное значение только для записи

or to

  • указать браузеру на сбой, что, скорее всего, приведет к ошибке сценария

Предложение? Или есть хорошие примеры из широко распространенных плагинов типа flash?

обновление:
Меня не интересует, полезны ли свойства только для записи или нет - мне не нравится эта идея, но я должен поддержать ее по историческим причинам.


javascript browser-plugin
person Georg Fritzsche    schedule 07.10.2009    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Существующая практика следует закону Постеля: "Будьте консервативны в том, что вы делаете; будьте либеральны в том, что вы принимаете". от других».

В этом случае это означает, что документация вашего плагина должна показывать правильное использование, но она должна допускать неправильное использование. Мудрость этого подхода должна быть очевидна из изучения успеха HTML по сравнению с любой другой гипертекстовой системой, которая появилась раньше или была изобретена позже. Большинство неудач были связаны с кабалой и дисциплиной, где малейшая ошибка приводила к тому, что документ становился нечитаемым.

Точно так же, как люди регулярно пишут плохой HTML, некоторые из ваших пользователей, вероятно, передают вам неверный ввод. Скажем, у вас есть логическое свойство, задокументированное как "истина" или "ложь". Что делать, если вы получите 1 или 0? Должен ли он рухнуть или просто справиться? Закон Постеля гласит: справляться. Что делать, если вы получите -1? Опять же, справьтесь, например, выбрав правило C, согласно которому ненулевое значение является «истинным». Переходя к вашему конкретному вопросу, если логическое свойство задокументировано как доступное только для чтения, и кто-то дает ему значение, ваш плагин должен просто съесть его.

Вся эта специальная обработка случаев требует от вас большего количества кода, но делает ваш плагин более простым в использовании и, следовательно, более популярным.

Другая половина закона Постела означает, что свойства только для чтения должны иметь только задокументированные значения. Опять же, возьмем случай логического свойства: если ваши документы говорят, что значение «истинно» или «ложно», никогда не возвращайте вместо этого «1», даже если JavaScript понимает, что это истинное значение. Следуйте своим собственным спецификациям, даже если вы пишете код, который позволяет другим безнаказанно нарушать его.

Кстати, мне не нравится идея свойств только для записи. Вместо этого вы должны сделать эти функции. То есть:

pluginInstance.setWriteOnlyProperty(5);

нет:

pluginInstance.writeOnlyProperty = 5;

Переменные только для чтения — это хорошо понятные вещи. Переменные только для записи встречаются редко. Единственный раз, когда я когда-либо видел его, был в маленьком 8-битном микроконтроллере, и причина этого была ясна из-за конструкции оборудования. Я не вижу места для таких хороших оправданий в программном обеспечении.

person Warren Young    schedule 09.10.2009
comment
Проблема с этим подходом заключается в том, что если неправильное использование работает, вы неявно обязуетесь всегда его поддерживать. - person erikkallen; 10.10.2009
comment
См. также joelonsoftware.com/articles/Unicode.html, где Джоэл Спольски рассказывает о том, как Закон Постеля, откровенно говоря, не очень хороший инженерный принцип. - person Kev; 10.10.2009
comment
Это жизнь во всемирно распределенной системе. Вы не можете навязать хорошее поведение, и вы не можете вовлечь всех клиентов в текущую практику. Если вы не желаете следовать закону Постеля, вы не должны пытаться создать что-то, что будет использоваться во всем мире в течение десятилетия или более, потому что люди в конечном итоге будут разочарованы любой системой, которая либо постоянно меняет свой протокол, либо ломается, когда вы бросаете в него неверные данные. - person Warren Young; 10.10.2009
comment
Спольски может быть прав, когда речь идет об относительно небольших системах, где у поставщика технологий есть разумная надежда повлиять на всех своих пользователей. Он полностью ломается в любой системе мирового масштаба, такой как HTML или плагины для браузера от производителей, стремящихся к популярности. Каждый, кто играет в этой песочнице, в конце концов открывает для себя Закон Постеля. - person Warren Young; 10.10.2009
comment
Поддержка всех возможных злоупотреблений не очень полезна - если я ожидаю логическое свойство и пытаюсь неявно обрабатывать объекты или числа с плавающей запятой, это действительно становится странным. - person Georg Fritzsche; 10.10.2009
comment
И: я тоже не люблю писать только свойства, но нарушать существующую спецификацию, которую я унаследовал, еще хуже. - person Georg Fritzsche; 10.10.2009
comment
Re: Обрабатывая все возможные булевы значения, вам не нужно буквально рассматривать все возможности. Вам просто нужно сделать ваш синтаксический анализатор достаточно толерантным, чтобы, по крайней мере, выдавать разумное значение по умолчанию, когда у вас заканчиваются известные случаи, чтобы попробовать. Не кричите на пользователя, не ругайтесь, просто справляйтесь. Re: свойства только для записи, я не знал, что вы реализуете существующую спецификацию. Поскольку да, то и здесь вы должны следовать закону Постела: не меняйте поведение существующих пользователей. - person Warren Young; 10.10.2009
comment
А, я тоже не знала, что это требование. - person Kev; 10.10.2009
comment
В спецификации нет определенного поведения для записи свойств только для чтения и чтения только для записи - отсюда и вопрос. - person Georg Fritzsche; 10.10.2009
comment
Случаи только для чтения, которые я рассмотрел выше в своем ответе. Для случаев только для записи это зависит от того, была ли эта спецификация выпущена для других и закодирована. Если это так, я бы добавил параллельный набор функций установки, задокументировал бы форму свойства как неподдерживаемую, но по-прежнему принимал входные данные через эти интерфейсы. Любые расширения этих интерфейсов следует делать только для функций установки. Если никто еще не написал код для неработающей спецификации, вы можете спокойно изменить его. Если вам говорят, что вы не можете его изменить, укажите, что ни одна спецификация не выдерживает реализации. :) - person Warren Young; 10.10.2009
comment
Хотя я бы предпочел подход Кева, я думаю, что должен согласиться с вами в контексте вопроса. - person Georg Fritzsche; 15.10.2009

arrow_upward
1
arrow_downward

Я бы не стал молча отбрасывать значения, даже если вы очень четко объясните это в документах. Оператор, не возвращающий какую-либо ошибку, создает впечатление, что он должен иметь эффект. Отлаживать проще, если вы получаете четкое сообщение об ошибке ("Свойство x доступно только для чтения").

Я согласен с ответом Уоррена Янга, однако, что касается функций только для записи. Свойства только для записи неинтуитивны.

person Kev    schedule 09.10.2009
comment
2 ответа, 2 мнения. Хороший. Я тоже не люблю писать только свойства, но нарушать существующую спецификацию, которую я унаследовал, еще хуже. - person Georg Fritzsche; 10.10.2009
comment
На самом деле, мне тоже нравится философия раннего провала. Поедание ошибок усложняет отладку. Однако это по-прежнему нарушает принцип надежности, что важно, когда ваши пользователи находятся вне вашего влияния. Вы можете разделить разницу, предложив режим отладки, в котором ошибки помечаются, и производственный режим, в котором ошибки обрабатываются молча. Плагин Flash делает это, например. - person Warren Young; 10.10.2009
comment
Кстати, поучительно установить плагин для отладки Flash, а потом идти бродить по интернету несколько дней. Обратите внимание, сколько сайтов не работает в соответствии с его более строгой интерпретацией протокола плагина, но которые на самом деле функционируют достаточно хорошо, чтобы никто, не использующий плагин отладки, не заметил. Adobe знает закон Постела. - person Warren Young; 10.10.2009