Я недавно не смотрел на это, но, по крайней мере, в прошлом были некоторые проблемы с полной реализацией общего lisp в CLR, и я был бы немного удивлен, если это изменилось. Проблемы возникают с такими вещами, как обработка чисел с плавающей точкой, когда .net / clr имеет способ сделать это, а) слегка некорректный б) не согласный со стандартом ANSI для общего списка, но в) не позволяющий обойти это. Есть и другие подобные проблемы. Это неудобно и, возможно, не слишком важно, но означает, что вы вряд ли увидите CL CL ANSI на CLR.
Существуют более серьезные проблемы, например, обычный lisp имеет более мощную объектную систему, поэтому вы не можете сопоставить его 1: 1 с объектом во время выполнения (без MI, например). Это нормально, но оставляет вам подход внутри / снаружи, которого обычная среда выполнения старается избегать ...
Видишь ли ты, что на нем работает распространенный вариант с недоверием, - это отдельная история, но на данный момент я не знаю ни одной (не то, чтобы я выглядел очень усердно)
Крокфорду не нравятся новые
. Следовательно, JSLint ожидает, что вы будете избегать его , когда это возможно. И создание нового объекта массива возможно без использования new
....
Нет ничего плохого ни в одной из форм, но обычно вы видите, что литералы используются везде, где это возможно-
var s = '' не вернее, чем var s = new String ( ) ....
В первом синтаксисе как таковом нет ничего плохого. Фактически, в w3schools он перечисляет new Array ()
как способ создания массива. Проблема в том, что это «старый способ». «Новый способ» []
короче и позволяет инициализировать значения в массиве, как в [«foo», «bar»]
. Большинство разработчиков предпочитают []
new Array ()
с точки зрения хорошего стиля.
Я сам задал тот же вопрос в здесь и только что опубликовал ответ, который недавно нашел. Краткий ответ: введите SecurityContext
,