Mục đích của việc cho phép tên thuộc tính trùng lặp là gì?

Question

Tôi đọc MDN javascript reference, theo đoạn mã sau không còn trả false:

function haveES6DuplicatePropertySemantics(){ 
    "use strict"; 
    try { 
    ({ prop: 1, prop: 2 }); 

    // No error thrown, duplicate property names allowed in strict mode 
    return true; 
    } catch (e) { 
    // Error thrown, duplicates prohibited in strict mode 
    return false; 
    } 
} 

In ECMAScript 5 strict mode code, duplicate property names were considered a SyntaxError. With the introduction of computed property names making duplication possible at runtime, ECMAScript 6 has removed this restriction.

Câu hỏi của tôi là, lợi ích thiết thực của việc cho phép trùng lặp bất động sản-tên trong initializers là gì? Tôi có thể thấy, khi các thuộc tính của đối tượng được gán động, điều này đôi khi có thể xảy ra, nhưng vì thứ tự ưu tiên rõ ràng xác định thuộc tính nào thực sự được đặt trên đối tượng mới được tạo ra - điều này có vẻ hơn bất kỳ thứ gì giống như hành vi không xác định.

Answer 1

what are the practical benefits of allowing duplicate property-names in the initializers

Không có lợi ích thiết thực như vậy. Bây giờ có các khóa thuộc tính được tính toán trong ECMA Script 6, giá trị thực của các khóa sẽ chỉ được xác định tại thời gian chạy. Vì nó là, các khóa có thể được thêm vào các đối tượng trong thời gian chạy và chúng ghi đè khóa và giá trị hiện tại. Hành vi tương tự được mở rộng trong ES-6 và việc hạn chế không cho phép kiểm tra các nút trùng lặp thời gian trùng lặp được loại bỏ.

Trích dẫn Allen Wirfs-Brock từ discussion in ESDiscuss Mailing list,

The plan has been that runtime validation would be performed for any object literals containing computed property keys and the current spec. draft contains pseudo code for doing the checks. However a bug report (https://bugs.ecmascript.org/show_bug.cgi?id=1863 ) points out an issue with the current spec. For example, the current spec. throws an error on:

({get a() {}, 
    get ["a"]() {} 
}); 

but not on:

({get ["a"]() {}, 
    get a() {} 
}); 

Basically, it isn't sufficient to only check for an already defined property key when processing property definitions that contains a computed key. If any computed keys exist the checking has to be done even for the definitions that have literal property names. And it isn't sufficient to just consider the property keys and the data/accessor property distinction, the validation also has to take into account the syntactic form of the definition and whether or not strict mode applies..

It turns out that even in pseudo code, this is a fairly complicated set of runtime validation rules to apply. I'm having a hard time convincing myself that the runtime computational and meta data costs of this dynamic validation is justified. It costs too much and the actual benefit is pretty small.

For that reason, I propose that we drop this runtime validation of object literals (and class definition). We would still have the static validation and early errors for property definitions that don't have computed keys. But anything that makes it past those checks (including all property definitions with computed names) are just processed sequentially with no duplicate name checking.

Vì vậy, đề nghị là để giữ lại kiểm tra thời gian biên dịch cho phím bình thường và as per this comment kiểm tra đã bị bỏ sau đó. Trong Revision 26,

Eliminated duplicate property name restrictions on object literals and class definitions