Пользовательские коллекции и изменчивость в Coffeescript - PullRequest
Новая
       10

Пользовательские коллекции и изменчивость в Coffeescript

2 голосов
/ 02 октября 2011

Я читаю о CoffeeScript и все еще пытаюсь определить язык, что можно сделать, каковы лучшие практики и т. Д .;Я больше привык к языкам со строгой типизацией (AS3, Java, Scala), поэтому мои два вопроса могут заставить вас немного улыбнуться:)

Вопрос 1: Пользовательские коллекции

Что вы думаете оСобственные коллекции?JS / CS является одним из самых слабых языков в этом аспекте;Например, нет никакого Array.remove, и вы должны использовать громоздкий метод splice ().Некоторые библиотеки функций (например, подчеркивание) расширяют API, предоставляя функции, принимающие массивы / объекты в качестве первого аргумента, но при выборе я предпочел бы написать: 

list fancyFunction 3, 4

вместо 

fancyFunction list 3, 4
* 1010Допустим, я создаю класс List;Возможно ли, и если да, каковы требования для этого класса, чтобы иметь возможность использовать синтаксис понимания CS?В худшем случае, я думаю, у List может быть метод toArray (), и вместо этого могут быть выполнены обычные CS-операции с этим возвращаемым значением, но я надеюсь, что есть лучшее решение.

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

Вопрос 2: Изменчивость

Что люди думают о том, что они очень осторожны с изменчивостью в CS / JSв целом?

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

Например, изменяемыйпо сравнению с неизменным базовым классом Point: (надеюсь, я не делаю что-то не так)

изменяемый 

class Point
  constructor: (@x, @y) ->

неизменяемый 

class Point
  constructor: (x, y) ->
    @x = -> x
    @y = -> y

Не намного сложнее, но немного страннеесинтаксис.Другое соображение заключается в том, что JS - не самая быстрая вещь, известная человеку, и необходимость создавать множество объектов в цикле просто ради того, чтобы быть пуристом, может быть контрпродуктивной, с точки зрения производительности.Я не сравнивал стоимость создания новых объектов Point с изменением их членов.

Представьте себе большое приложение с множеством модулей, взаимодействующих через тонкие API.Разве вы не хотели бы передавать неизменные объекты вокруг?Или вы вместо этого выполняете защитные копии?

Примечание: я не пытаюсь согнуть CS в знакомых мне языках;Скорее, я хочу знать, имеет ли смысл повторно использовать некоторые концепции, принимаемые как должное в других языках.

Спасибо

1 Ответ

6 голосов
/ 02 октября 2011

Я думаю, что короткий ответ на это таков: JavaScript универсален, но небезопасен. Статических типов не существует, и ничто не является неизменным (за исключением случаев, когда вы изолированы в другой области видимости). Некоторые люди пытаются бороться с этой слабостью - например, Google сильно аннотирует свой код в стиле JavaDoc. Но обычные программисты на JavaScript этого не делают. Они редко скрывают переменные экземпляра за геттерами или генерируют исключения, когда вы вызываете их API со строкой, когда они ожидали логическое значение. Отчасти это по практическим соображениям - JS - единственный из известных мне языков, где люди обычно говорят о размере байта своего кода, - но он также отражает окружающую культуру языка, где документация и тесты оцениваются намного выше, чем ручная работа.

Короче, я бы придерживался 

constructor: (@x, @y) ->

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

Кстати, Underscore предоставляет альтернативный синтаксис, который позволяет писать код в нужном порядке: 

_(list).remove ...

Или вы можете расширить прототип [Array]. См. Sugar.js для некоторых прекрасных примеров.

...