не может определить конструктор как связанную функцию - PullRequest
2 голосов
/ 17 февраля 2012
class A 
   constructor: ->
   method: ->

В приведенном выше примере метод не привязан к классу и не является конструктором.

class B 
   constructor: ->
   method: =>

В этом случае метод привязан к классу. Он ведет себя так, как вы ожидаете, что нормальный объектный метод будет вести себя, и имеет доступ ко всем полям класса B. Но конструктор не связан? Это кажется странным. Поэтому я попробовал следующее.

class C 
   constructor: =>
   method: =>

Это не компилируется. Я ожидаю, что синтаксис будет одинаковым для всех методов, которые связаны с классом.

Я хотел бы рассматривать оператор -> как оператор static, а оператор => как оператор dynamic. Но не похоже, что ты можешь. Если бы вы могли, метод с оператором -> не мог бы быть вызван с супер. Но на самом деле вы можете. Почему это имеет смысл для синтаксиса объектно-ориентированного языка? Кажется, это не соответствует большинству правил наследования объектно-ориентированных языков.

Ответы [ 2 ]

4 голосов
/ 17 февраля 2012

Попробуйте посмотреть, как код компилируется. Когда вы используете =>, методы связываются внутри конструктора. Таким образом, нет смысла использовать => для конструктора - когда он будет связан?

Я не уверен в вашей проблеме с static против dynamic операторов, но вы определенно можете вызывать методы, определенные с помощью оператора -> с super. Единственное, на что влияет -> против =>, это то, что => гарантирует, что this - это рассматриваемый объект независимо от того, как он называется.

Сводка комментариев:

Вызов разницы между -> и => аналогично статическому или динамическому (или виртуальному) не совсем передает то, что делают эти операторы. Они используются, чтобы получить другое поведение из переменной this javascript. Например, посмотрите на следующий код:

class C
  constructor: ->
  method1: ->
    console.log this
  method2: =>
    console.log this

c = new C()

c.method1()        //prints c
f = c.method1;f()  //prints window

c.method2()        //prints c
f = c.method2;f()  //prints c

Различие заключается во втором способе, которым мы вызываем каждый метод: если метод не "привязан" к объекту, его this устанавливается путем просмотра того, что предшествует вызову метода (разделенного .). В первом случае это c, но во втором f не вызывается для объекта, поэтому this имеет значение window. method2 не имеет этой проблемы, потому что он связан с объектом.

Обычно вы можете думать, что функция конструктора автоматически связывается с объектом, который она создает (таким образом, вы не можете связать ее с =>). Однако стоит отметить, что это не совсем то, что происходит, потому что если конструктор возвращает объект, это будет возвращаемое значение конструкции, а не this во время конструктора.

1 голос
/ 18 февраля 2012

Я думаю, вы сильно запутались в значении '=>' или жирной стрелки.

Во-первых, ваши примеры на самом деле не верны, не так ли? Нет -> после объявления класса. Добавление одного является ошибкой компилятора.

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

Аналог C ++, возможно, говорит о том, что жирная стрелка - это метод автоматического создания функтора: она позволяет передать функцию в качестве обратного вызова третьей стороне, которая может вызвать ее, не зная вашего объекта, но где код Вызванный внутри будет иметь доступ к вашему объекту как указатель this. Он не служит никаким другим целям и не имеет отношения к тому, может ли функция быть перегружена или может ли она иметь доступ к super.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...