Backbone: 메서드를 확장하기 위해 getter/setter 지원 추가

person.fullName() 로 작성하는 것이 더 좋지 않은 이유가 있습니까? 그래서 그것이 함수 호출이라는 것을 알 수 있습니까?

getter와 setter를 사용하는 것은 대부분 JS에서 나쁜 생각이며 백본 모델의 핵심 아이디어 중 하나에 위배됩니다. 조만간 지원이 추가되는 것을 볼 수 있을지 모르겠습니다.

무엇보다 이것은 새로운 클래스 구문과 부분적으로 정렬됩니다. 클래스 구문에 속성 이니셜라이저가 없으며 아직 이에 대한 사양도 없으므로 interop이 문제가 될 것입니다.

그들은 백본 모델의 핵심 아이디어 중 하나에 반대합니다.

그게 무슨 핵심 아이디어야?

또한 getter는 model.idAttribute 를 사용하여 Backbone.Collection의 기존 문제에 대한 부분적인 솔루션입니다.

다른 솔루션으로 jsperf를 만드는 데 몇 분을 보냈습니다.
http://jsperf.com/backbone-extend-with-define-property

그게 무슨 핵심 아이디어야?

개체의 속성을 설정하고 검색하는 것은 투명하고 논리적이어야 한다는 생각입니다. obj.prop = val 는 해당 속성 값을 설정하는 것 외에는 다른 작업을 수행하지 않는다는 것을 항상 알고 있어야 하며(검색의 경우도 마찬가지), 계산된 속성 및 변경 이벤트와 같은 작업을 처리하기 위해 함수를 사용해야 합니다. 이것이 attributes 주위에 $ get 및 set 래퍼 메서드가 있는 주된 이유입니다.

또한 getter는 model.idAttribute가 있는 Backbone.Collection의 기존 문제에 대한 부분적인 솔루션입니다.

현재 _.result 래퍼가 작동하지 않는 이유가 무엇입니까? idAttribute 는 기본 또는 함수일 수 있습니다. 이것은 modelId 로도 수정되고 있습니다.

내가 말한 문제에 연결했어야 해서 죄송합니다: https://github.com/jashkenas/backbone/issues/3408

저는 주로 Backbone의 클래스 구문이 ES 클래스 구문과 거의 호환되기 때문에 이 문제를 제기하고 있으며, coffeescript에 대한 추가 지원을 고려할 때 호환되는 것이 합리적으로 보입니다.

CoffeeScript는 대부분 같은 이유로 setter와 getter를 지원하지 않습니다(https://github.com/jashkenas/coffeescript/pull/2902부터 시작하여 몇 가지 배경에 대한 문제 살펴보기). 백본 객체를 클래스로 지원하는 데 장애물이 되어서는 안 됩니다.

내가 말한 문제에 연결했어야 해서 죄송합니다. #3408

상기시켜줘? 나는 방망이에서 연결을 보기 위해 긴장하고 있습니다.

게다가 extend 에 대한 모든 변경 사항은 여기가 아닌 _.extend 에서 수행해야 합니다. Wontfix로 닫습니다.

CoffeeScript는 대부분 같은 이유로 setter와 getter를 지원하지 않습니다.

나는 getter/setter에 대해 말하는 것이 아니라 Backbone이 CoffeeScript와의 상호 운용성을 위해 __super__ 를 추가한 방법과 동일한 방식으로 ES6 클래스를 지원하는 것만이 의미가 있는 방법에 대해 이야기하고 있었습니다.

상기시켜줘? 나는 방망이에서 연결을 보기 위해 긴장하고 있습니다.

Collection.extend({
  model: function() { return Model }
});
//
collection.modelId(model); // 'id' regardless if that's correct or not.

Collection.extend({
  get model() { return Model }
});
//
collection.modelId(model); // correct for *some* of the common cases.

게다가 확장할 모든 변경 사항은 여기가 아닌 _.extend에서 수행해야 합니다. Wontfix로 닫습니다.

새로운 _.assign 메소드에 있을 수 있는 변경 사항이 있는 경우 이는 확실히 이 변경 사항에 적합한 위치가 아닙니다. 그러나 IMO에서 지원하는 것이 훨씬 더 합리적입니다.

또한 이 문제가 종료되고 잊혀지기 전에 Backbone의 확장에 ES 클래스와 상호 운용성 문제가 있지만 CoffeeScript 클래스에는 문제가 없는 이유를 설명하고 싶습니다.

IE Tech Preview가 class (Traceur 및 6to5도 아직 extends 를 변환하지 않음)를 원격으로 제대로 지원하는 유일한 브라우저 이기 때문에 우리는 이것과는 거리가 멀습니다. 필요한. 백본은 처음부터 좋은 아이디어가 아닌 기능을 지원하기 위해 이전 버전과의 호환성을 깨는 방법을 사용하지 않을 것입니다.

Tracer와 6to5도 아직 extends 변환하지 않습니다.

둘 다 실제로는 널리 지원되는 정적 속성에 대해 __proto__ 에 대한 지원만 필요합니다.

또한 백워드 호환성을 깨야 할 이유가 없으며 가능한 경우 Object.setPrototypeOf 를 선택적으로 사용하면 더 빠르게 만들 수 있습니다.

@thejameskyle 이것을 이슈가 아닌 PR로 바꾸고 싶으신가요? 살펴볼 가치가 있습니다.

물론이죠, 그렇게 하겠습니다

가는 중인가요? 요점이나 그것에 대해 뭔가가 있습니까? 촬영을 하고 싶습니다.