Написание программ на динамических языках, выходящих за рамки спецификации.

Question

С развитием динамически типизированных языков, поскольку они дают нам больше гибкости, весьма вероятно, что люди будут писать программы, выходящие за рамки того, что позволяет спецификация.

На мое мышление повлиял этот вопрос, когда я прочитал ответ bobince:Вопрос о методах среза и сращивания JavaScript.

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

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

Это проблема или естественное продолжение написания таких гибких языков?Или нам следует ожидать, что такие инструменты, как JSLint, помогут контролировать спецификацию?

Мне понравился один ответ в этом вопросе: реализация Python — это спецификация.Мне любопытно, действительно ли это ближе к истине для этих типов языков: если язык позволяет вам что-то делать, то это указано в спецификации.Существует ли спецификация языка Python?

ОБНОВЛЯТЬ:

Прочитав пару комментариев, я решил проверить метод сращивания в спецификации, и вот что я нашел внизу страницы 104: http://www.mozilla.org/js/language/E262-3.pdf, поэтому получается, что я могу использовать сращивание дочернего массива, не нарушая спецификацию.Я просто не хочу, чтобы люди увязли в моем примере, но, надеюсь, обдумаю этот вопрос.

    The splice function is intentionally generic; it does not require that its this value be an Array object. 
Therefore it can be transferred to other kinds of objects for use as a method. Whether the splice function 
can be applied successfully to a host object is implementation-dependent.

ОБНОВЛЕНИЕ 2:Меня интересует не Javascript, а гибкость языка и его характеристики.Например, я ожидаю, что в спецификации Java указано, что вы не можете помещать код в интерфейс, но, используя AspectJ, я делаю это часто.Вероятно, это нарушение, но авторы не предсказывали АОП, и инструмент был достаточно гибким, чтобы его можно было использовать для этого, так же как JVM также достаточно гибка для Scala и Clojure.

Answer 1

Я думаю, что такая гибкость является преимуществом, если ваши методы разработаны на основе четко определенных интерфейсов, а не каких-то искусственных внешних метаданных «типа».Большинство функций массива ожидают только объект со свойством длины.Тот факт, что все они могут применяться в общих чертах к множеству различных типов объектов, является благом для повторного использования кода.

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

Напротив, методы массива проверяют свои входные значения, чтобы определить, есть ли у них то, что им нужно для выполнения своей функции.Это утиная типизация, и я считаю, что это более научно и «правильно», и в результате получается более многократно используемый код, а это то, что вам нужно.Вам не нужен метод, отклоняющий ваши входные данные, потому что у них не в порядке свои документы.Это коммунизм.

Answer 2

Является ли язык статически или динамически типизированным, на самом деле здесь небольшая часть проблемы:статически типизированный может немного облегчить коду соблюдение его спецификаций, но незначительно здесь ключевое слово.Только «проектирование по контракту» — язык, позволяющий явно указывать предусловия, постусловия и инварианты, а также обеспечение соблюдения их - может помочь вам защититься от пользователей ваших библиотек, эмпирически обнаруживающих, что именно библиотека позволяет им сойти с рук, и использования этих открытий для выхода за рамки ваших дизайнерских замыслов (возможно, ограничивая вашу будущую свободу в изменении дизайна или его реализации). ).А «проектирование по контракту» не поддерживается в основных языках — Eiffel ближе всего к этому, и в наши дни мало кто назовет его «мейнстримом» — по-видимому, потому, что его затраты (в основном, неизбежно во время выполнения) не кажутся значительными. оправдано своими преимуществами.«Аргумент x должен быть простым числом», «метод A должен быть вызван ранее, прежде чем можно будет вызвать метод B», «метод C больше не может быть вызван после вызова метода D» и т. д. — типичные виды ограничений, которые вы бы нравиться заявлять (и применять неявно, без необходимости тратить значительное время и силы на программирование, проверяя их самостоятельно) просто не поддаются созданию в контексте того немногого, что может обеспечить компилятор статически типизированного языка.

Answer 3

Я не думаю, что ваш вопрос действительно имеет какое-либо отношение к динамическому или динамическому.статическая типизация.Действительно, я вижу два случая:с одной стороны, есть такие вещи, как устройство Даффа, о котором упоминал Мартин Клейтон;такое использование крайне удивительно, когда вы видите его впервые, но оно явно разрешено семантикой языка.Если существует стандарт, такая идиома может появиться в более поздних редакциях стандарта в качестве конкретного примера.В этом нет ничего плохого;на самом деле, они могут (если ими не злоупотреблять) значительно повысить производительность.

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

Answer 4

Мне кажется, что первоначальный вопрос немного нелогичный.Если спецификация явно допускает определенное поведение (например, ДОЛЖНО, МОЖЕТ, ДОЛЖНО или СЛЕДУЕТ), то любой компилятор/интерпретатор, который разрешает/реализует такое поведение, по определению совместим с языком.Похоже, что это ситуация, предложенная ОП в разделе комментариев - спецификация JavaScript предположительно* говорит, что рассматриваемая функция МОЖЕТ использоваться в разных ситуациях, и, следовательно, это явно разрешено.

Если, с другой стороны, компилятор/интерпретатор реализует или разрешает поведение, которое явно запрещено спецификацией, то компилятор/интерпретатор по определению работает вне спецификации.

Существует еще третий сценарий и связанный с ним четко определенный термин для тех ситуаций, когда спецификация не определяет поведение:неопределенный.Если спецификация фактически не определяет поведение в конкретной ситуации, то поведение не определено и может обрабатываться компилятором/интерпретатором либо намеренно, либо непреднамеренно.В этом случае разработчик несет ответственность за понимание того, что поведение не является частью спецификации, и, если он/она решит использовать это поведение, приложение разработчика, таким образом, будет зависеть от конкретной реализации.Интерпретатор/компилятор, обеспечивающий эту реализацию, не обязан поддерживать официально неопределенное поведение, помимо обратной совместимости и любых обязательств, которые может взять на себя производитель.Более того, более поздняя итерация спецификации языка может определить ранее неопределенное поведение, в результате чего компилятор/интерпретатор либо (а) будет несовместим с новой итерацией, либо (б) выпустит новый патч/версию, чтобы стать совместимым, тем самым ломая старые версии.

* «предположительно», потому что я сам не видел спецификации.Я исхожу из заявлений, сделанных выше.