Tại sao không phải là phương pháp của một đối tượng được tạo ra với lớp được ràng buộc với nó trong ES6?

Question

Tôi thích lớp ES6 nhưng tôi không thể hiểu tại sao tôi phải ràng buộc phương pháp trong nhà xây dựng như thế này:

constructor() { 
    this.someMethod = this.someMethod.bind(this) 
} 

tôi cần phải làm điều này gần như cho phương pháp bất kỳ.

Đây có phải là giới hạn thực sự hay tôi thiếu gì đó không? lý do đằng sau này là gì? Tôi biết rằng các lớp trong JS chỉ là cú pháp, nhưng điều này có thể là một phần của chúng.

Answer 1

Trích dẫn câu trả lời Mark Miller để the linked esdiscuss post đây:

Một số đề nghị lớp đầu đã làm như vậy, vì họ đã bắt đầu với ngữ nghĩa của các đối tượng-as-đóng cửa ES5 và các lớp học như tác phẩm-of-instance- đặc điểm.

doku.php?do=search&id=traits

Ý tưởng là hỗ trợ ngôn ngữ sẽ làm cho ngữ nghĩa này hiệu quả, tránh sự cần thiết phải phân bổ một háo hức đóng cửa mỗi phương pháp cho mỗi trường hợp.

Tuy nhiên, vì lý do tôi hiểu, những lỗi này không đạt được lực kéo. Thay vào đó, chúng tôi di chuyển theo hướng đường cho mẫu es5 thống trị của các lớp mã hóa thành kế thừa nguyên mẫu. Ban đầu, chúng tôi đã cố gắng để có điều này hoàn toàn là đường, để mọi người có thể tái cấu trúc mã một cách không đau đớn trong mô hình chi phối đó vào các lớp học.

Khi chúng ta vật lộn với ngữ nghĩa chi tiết xung quanh siêu và xây dựng, các lớp học es6 lệch khỏi đường tinh khiết. Nhưng độ lệch này chỉ ngăn cản việc tái cấu trúc không đau từ các lớp es6 thành mẫu es5 trội. Thực tế, nó vẫn không đau để cấu trúc lại từ mẫu es5 thành các lớp es6.

Tại zenparsing/es-function-bind#17 chúng tôi nhận ra

chúng ta vẫn có thể có phương pháp ràng buộc vào khai thác - chiếm hành vi bằng cách decreeing rằng phương pháp được cài đặt trên nguyên mẫu như accessors có getter với phím tắt. Tuy nhiên, việc thực hiện này đã quá muộn cho es6. Vì nó sẽ làm cho việc tái cấu trúc thành các lớp học nguy hiểm hơn - nhiều hơn một sự thay đổi ngữ nghĩa - nó không rõ ràng nó sẽ bay ngay cả khi chúng ta đã nghĩ về nó trong thời gian. Thay vào đó, dưới tất cả các biến thể của các thiết kế trang trí, người ta có thể viết một trình trang trí như vậy để các phương thức trang trí được ràng buộc-khai thác, bằng cách tạo một cách rõ ràng thuộc tính accessor này. Tuy nhiên (!), Nếu được thực hiện như là một trang trí người dùng, điều này có hiệu suất tồi tệ hơn nhiều so với các đối tượng-như-đóng cửa !! Các đối tượng-như-đóng cửa có chi phí phân bổ cao hơn khi phân bổ đối tượng.

jsperf.com/creating-stateful-objects

Nhưng là khá hiệu quả trong việc sử dụng các đối tượng khi đối tượng được tạo ra:.

jsperf.com/strict-where-state

(Lưu ý jsperf được misidentifying Cạnh 28.14257.1000.0 như Chrome 46.0.2486 Đây là đáng chú ý vì Edge sử dụng biểu diễn transposed cho WeakMaps, và vì vậy việc sử dụng WeakMap dựa trên trạng thái riêng tư có ít hình phạt trên Edge. Mặc dù điều này nằm ngoài điểm của chủ đề này.)

Để làm cho một trang trí cho ràng buộc-on-khai thác hiệu quả, một thực hiện sẽ cần một số loại trường hợp đặc biệt một nơi nào đó để tránh phân bổ khi phương pháp đang được gọi ngay lập tức, thay vì được quan sát chiết xuất.Điều duy nhất mà TC39 cần làm để cho phép điều này là chuẩn hóa một trình trang trí như vậy để các triển khai có thể cung cấp nó như là một nội trang dựng sẵn mà chúng nhận ra.

Và Kevin Smith của câu trả lời:

Nói chung, thường có một sự căng thẳng giữa làm cho ngôn ngữ "tốt hơn" (đối với một số hệ thống giá trị chủ quan) và duy trì tính nhất quán. Tôi nghĩ duy trì tính nhất quán là cuộc gọi đúng trong trường hợp này.

---

Điều đó nói rằng, các public class fieldsproposal sẽ cho phép bạn xác định phương pháp dụ như

class Foo { 
    someMethod =() => { 
    // do stuff 
    } 
} 

(thay vì làm như vậy trong constructor).