Tại sao các toán tử do người dùng định nghĩa phổ biến hơn?

Một tính năng tôi bỏ lỡ từ các ngôn ngữ chức năng là ý tưởng rằng các toán tử chỉ là các hàm, vì vậy việc thêm một toán tử tùy chỉnh thường đơn giản như thêm một hàm. Nhiều ngôn ngữ thủ tục cho phép quá tải toán tử, do đó, trong một số trường hợp, toán tử vẫn là các hàm (điều này rất đúng trong D khi toán tử được truyền dưới dạng một chuỗi trong một tham số mẫu).

Dường như khi quá tải toán tử được cho phép, việc thêm các toán tử tùy chỉnh bổ sung thường là chuyện nhỏ. Tôi tìm thấy bài đăng trên blog này , lập luận rằng các toán tử tùy chỉnh không hoạt động tốt với ký hiệu infix vì các quy tắc ưu tiên, nhưng tác giả đưa ra một số giải pháp cho vấn đề này.

Tôi nhìn xung quanh và không thể tìm thấy bất kỳ ngôn ngữ thủ tục nào hỗ trợ các nhà khai thác tùy chỉnh bằng ngôn ngữ này. Có các bản hack (như macro trong C ++), nhưng hầu như không giống như hỗ trợ ngôn ngữ.

Vì tính năng này khá nhỏ để thực hiện, tại sao nó không phổ biến hơn?

Tôi hiểu rằng điều đó có thể dẫn đến một số mã xấu, nhưng trước đây đã không ngăn các nhà thiết kế ngôn ngữ thêm các tính năng hữu ích có thể dễ dàng bị lạm dụng (macro, toán tử ternary, con trỏ không an toàn).

Các trường hợp sử dụng thực tế:

• Triển khai các toán tử bị thiếu (ví dụ Lua không có toán tử bitwise)
• Mimic D's ~(nối mảng)
• DSL
• Sử dụng |như đường cú pháp kiểu Unix (sử dụng coroutines / máy phát điện)

Tôi cũng quan tâm đến ngôn ngữ mà làm phép nhà khai thác tùy chỉnh, nhưng tôi quan tâm nhiều hơn trong lý do tại sao nó đã được loại trừ. Tôi đã nghĩ đến việc sử dụng một ngôn ngữ kịch bản để thêm các toán tử do người dùng định nghĩa, nhưng tôi đã dừng lại khi nhận ra rằng tôi không thấy nó ở bất cứ đâu, vì vậy có lẽ có một lý do chính đáng tại sao các nhà thiết kế ngôn ngữ thông minh hơn tôi không cho phép.

Có hai trường phái tư tưởng trái ngược nhau trong thiết kế ngôn ngữ lập trình. Một là các lập trình viên viết mã tốt hơn với ít hạn chế hơn và hai là họ viết mã tốt hơn với nhiều hạn chế hơn. Theo tôi, thực tế là các lập trình viên giàu kinh nghiệm phát triển với ít hạn chế hơn, nhưng những hạn chế đó có thể có lợi cho chất lượng mã của người mới bắt đầu.

Các toán tử do người dùng định nghĩa có thể tạo mã rất thanh lịch trong tay có kinh nghiệm và mã hoàn toàn khủng khiếp bởi người mới bắt đầu. Vì vậy, liệu ngôn ngữ của bạn có bao gồm chúng hay không phụ thuộc vào trường phái tư tưởng của nhà thiết kế ngôn ngữ của bạn.

Đưa ra lựa chọn giữa các mảng ghép với ~ hoặc với "myArray.Concat (secondArray)", tôi có thể thích cái sau hơn. Tại sao? Bởi vì ~ là một ký tự hoàn toàn vô nghĩa chỉ có ý nghĩa của nó - đó là nối chuỗi - được đưa ra trong dự án cụ thể nơi nó được viết.

Về cơ bản, như bạn đã nói, các toán tử không khác với các phương thức. Nhưng trong khi các phương thức có thể được cung cấp các tên dễ hiểu, dễ hiểu để tăng thêm sự hiểu biết về dòng mã, thì các toán tử lại mờ đục và tình huống.

Đây là lý do tại sao tôi cũng không thích .toán tử của PHP (nối chuỗi) hoặc hầu hết các toán tử trong Haskell hoặc OCaml, mặc dù trong trường hợp này, một số tiêu chuẩn được chấp nhận phổ biến đang xuất hiện cho các ngôn ngữ chức năng.

Vì tính năng này khá nhỏ để thực hiện, tại sao nó không phổ biến hơn?

Tiền đề của bạn là sai. Nó không phải là tầm thường để thực hiện trực tiếp. Trong thực tế, nó mang lại một túi các vấn đề.

Chúng ta hãy xem các giải pháp được đề xuất trên thế giới trong bài viết:

• Không có quyền ưu tiên . Bản thân tác giả cho biết, không sử dụng quy tắc ưu tiên đơn giản không phải là một lựa chọn.
• Phân tích nhận thức ngữ nghĩa . Giống như bài báo nói, điều này sẽ đòi hỏi trình biên dịch phải có nhiều kiến ​​thức ngữ nghĩa. Bài viết không thực sự cung cấp một giải pháp cho điều này và để tôi nói với bạn, điều này đơn giản là không tầm thường. Trình biên dịch được thiết kế như một sự đánh đổi giữa sức mạnh và sự phức tạp. Cụ thể, tác giả đề cập đến một bước phân tích trước để thu thập thông tin liên quan, nhưng phân tích trước là không hiệu quả và trình biên dịch cố gắng rất nhiều để giảm thiểu việc phân tích cú pháp.
• Không có toán tử infix tùy chỉnh . Chà, đó không phải là một giải pháp.
• Giải pháp lai . Giải pháp này mang nhiều (nhưng không phải tất cả) những nhược điểm của phân tích nhận thức ngữ nghĩa. Cụ thể, do trình biên dịch phải coi các mã thông báo không xác định là có khả năng đại diện cho các toán tử tùy chỉnh, nên nó thường không thể tạo ra các thông báo lỗi có ý nghĩa. Nó cũng có thể yêu cầu định nghĩa của toán tử đã nói để tiến hành phân tích cú pháp (để thu thập thông tin loại, v.v.), một lần nữa yêu cầu một phân tích cú pháp bổ sung.

Nói chung, đây là một tính năng đắt tiền để thực hiện, cả về độ phức tạp của trình phân tích cú pháp và về hiệu suất, và không rõ ràng rằng nó sẽ mang lại rất nhiều lợi ích. Chắc chắn, có một số lợi ích đối với khả năng xác định toán tử mới nhưng ngay cả những toán tử gây tranh cãi (chỉ cần nhìn vào các câu trả lời khác cho rằng có toán tử mới không phải là một điều tốt).

Chúng ta hãy bỏ qua toàn bộ đối số "các nhà khai thác bị lạm dụng để gây hại cho khả năng đọc" và tập trung vào ý nghĩa thiết kế ngôn ngữ.

Các toán tử Infix có nhiều vấn đề hơn các quy tắc ưu tiên đơn giản (mặc dù nói thẳng ra, liên kết mà bạn tham chiếu tầm thường hóa tác động của quyết định thiết kế đó). Một là giải quyết xung đột: điều gì xảy ra khi bạn xác định a.operator+(b)và b.operator+(a)? Ưu tiên cái này hơn cái kia dẫn đến phá vỡ tài sản giao hoán dự kiến ​​của nhà điều hành đó. Ném một lỗi có thể dẫn đến các mô-đun sẽ làm việc bị hỏng một lần cùng nhau. Điều gì xảy ra khi bạn bắt đầu ném các loại dẫn xuất vào hỗn hợp?

Thực tế của vấn đề là các nhà khai thác không chỉ là chức năng. Các hàm độc lập hoặc được sở hữu bởi lớp của chúng, cung cấp một ưu tiên rõ ràng về tham số nào (nếu có) sở hữu công văn đa hình.

Và điều đó bỏ qua các vấn đề bao bì và độ phân giải khác nhau phát sinh từ các nhà khai thác. Lý do các nhà thiết kế ngôn ngữ (bằng và lớn) giới hạn định nghĩa toán tử trung gian là bởi vì nó tạo ra một đống vấn đề cho ngôn ngữ trong khi cung cấp lợi ích gây tranh cãi.

Và thẳng thắn, bởi vì chúng không tầm thường để thực hiện.

Tôi nghĩ bạn sẽ ngạc nhiên về mức độ thường xuyên quá tải của nhà điều hành được thực hiện trong một số hình thức. Nhưng chúng không được sử dụng phổ biến trong nhiều cộng đồng.

Tại sao sử dụng ~ để nối với một mảng? Tại sao không sử dụng << như Ruby không ? Bởi vì các lập trình viên bạn làm việc cùng có lẽ không phải là lập trình viên Ruby. Hoặc lập trình viên D. Vậy họ làm gì khi gặp mã của bạn? Họ phải đi và tìm kiếm những gì biểu tượng có nghĩa.

Tôi đã từng làm việc với một nhà phát triển C # rất giỏi, người cũng có sở thích về ngôn ngữ chức năng. Ra khỏi màu xanh, ông bắt đầu giới thiệu monads C # bằng cách phương pháp khuyến nông và sử dụng thuật ngữ đơn nguyên tiêu chuẩn. Không ai có thể tranh cãi rằng một số mã của anh ta đã bị thay đổi và thậm chí còn dễ đọc hơn một khi bạn biết ý nghĩa của nó, nhưng điều đó có nghĩa là mọi người phải học thuật ngữ đơn âm trước khi mã có ý nghĩa .

Đủ công bằng, bạn nghĩ sao? Đó chỉ là một đội nhỏ. Cá nhân, tôi không đồng ý. Mỗi nhà phát triển mới đã được định sẵn để bị nhầm lẫn bởi thuật ngữ này. Chúng ta không có đủ vấn đề khi học một tên miền mới?

Mặt khác, tôi sẽ vui vẻ sử dụng các ??toán tử trong C # vì tôi mong đợi các nhà phát triển C # khác để biết nó là gì, nhưng tôi sẽ không quá tải nó thành một ngôn ngữ mà không hỗ trợ nó theo mặc định.

Tôi có thể nghĩ ra một vài lý do:

• Chúng không tầm thường để thực hiện - cho phép các toán tử tùy chỉnh tùy ý có thể làm cho trình biên dịch của bạn phức tạp hơn nhiều, đặc biệt nếu bạn cho phép các quy tắc ưu tiên, sửa lỗi và quy tắc do người dùng xác định. Nếu sự đơn giản là một ưu điểm, thì quá tải toán tử sẽ đưa bạn ra khỏi thiết kế ngôn ngữ tốt.
• Họ bị lạm dụng - chủ yếu bởi các lập trình viên nghĩ rằng thật tuyệt vời khi xác định lại các toán tử và bắt đầu xác định lại chúng cho tất cả các loại lớp tùy chỉnh. Chẳng bao lâu, mã của bạn chứa đầy các ký hiệu tùy chỉnh mà không ai khác có thể đọc hoặc hiểu được vì các toán tử không tuân theo các quy tắc được hiểu rõ thông thường. Tôi không mua đối số "DSL", trừ khi DSL của bạn là tập con của toán học :-)
• Chúng làm tổn thương khả năng đọc và khả năng bảo trì - nếu các nhà khai thác thường xuyên bị ghi đè, có thể khó phát hiện khi cơ sở này đang được sử dụng và các lập trình viên buộc phải liên tục tự hỏi người vận hành đang làm gì. Nó là tốt hơn nhiều để cung cấp tên chức năng có ý nghĩa. Gõ thêm một vài ký tự là rẻ, vấn đề bảo trì dài hạn là tốn kém.
• Họ có thể phá vỡ kỳ vọng hiệu suất ngầm . Ví dụ, tôi thường mong đợi việc tra cứu một phần tử trong một mảng O(1). Nhưng với quá tải toán tử, someobject[i]có thể dễ dàng là một O(n)hoạt động tùy thuộc vào việc thực hiện toán tử lập chỉ mục.

Trong thực tế, có rất ít trường hợp quá tải toán tử có công dụng chính đáng so với việc chỉ sử dụng các chức năng thông thường. Một ví dụ hợp pháp có thể là thiết kế một lớp số phức được sử dụng bởi các nhà toán học, những người hiểu các cách hiểu rõ mà các toán tử toán học được định nghĩa cho các số phức. Nhưng đây thực sự không phải là một trường hợp rất phổ biến.

Một số trường hợp thú vị để xem xét:

• Lisps : nói chung không phân biệt tất cả giữa các toán tử và hàm - +chỉ là một hàm thông thường. Bạn có thể xác định các chức năng theo cách bạn thích (thông thường có một cách xác định chúng trong các không gian tên riêng biệt để tránh xung đột với tích hợp +), bao gồm các toán tử. Nhưng có một xu hướng văn hóa là sử dụng các tên hàm có ý nghĩa, vì vậy điều này không bị lạm dụng nhiều. Ngoài ra, trong ký hiệu tiền tố Lisp có xu hướng được sử dụng riêng, do đó, có ít giá trị hơn trong "đường cú pháp" mà quá tải toán tử cung cấp.
• Java - không cho phép quá tải toán tử. Điều này đôi khi gây khó chịu (đối với những thứ như trường hợp số phức) nhưng trung bình có lẽ đó là quyết định thiết kế đúng cho Java, được dùng như một ngôn ngữ OOP đơn giản, có mục đích chung. Mã Java thực sự khá dễ dàng đối với các nhà phát triển có tay nghề thấp / trung bình để duy trì do sự đơn giản này.
• C ++ có quá tải toán tử rất tinh vi. Đôi khi điều này bị lạm dụng ( cout << "Hello World!"bất cứ ai?) Nhưng cách tiếp cận có nghĩa là định vị của C ++ là một ngôn ngữ phức tạp cho phép lập trình cấp cao trong khi vẫn cho phép bạn tiến gần đến kim loại để thực hiện, vì vậy bạn có thể viết một lớp Số phức hoạt động chính xác như bạn muốn mà không ảnh hưởng đến hiệu suất. Điều này được hiểu rằng đó là trách nhiệm của riêng bạn nếu bạn tự bắn vào chân mình.

Vì tính năng này khá nhỏ để thực hiện, tại sao nó không phổ biến hơn?

Nó không tầm thường để thực hiện (trừ khi thực hiện tầm thường). Nó cũng không giúp bạn có được nhiều thứ, ngay cả khi được thực hiện một cách lý tưởng: mức tăng khả năng đọc được từ sự căng thẳng được bù đắp bằng những mất mát có thể đọc được từ sự không quen thuộc và độ mờ đục. Nói tóm lại, nó không phổ biến vì nó thường không xứng đáng với thời gian của nhà phát triển hoặc người dùng.

Điều đó nói rằng, tôi có thể nghĩ về ba ngôn ngữ làm điều đó và họ làm điều đó theo những cách khác nhau:

• Vợt, một lược đồ, khi nó không phải là tất cả biểu thức S cho phép và mong bạn viết một số tiền cho trình phân tích cú pháp cho bất kỳ cú pháp nào bạn muốn mở rộng (và cung cấp các móc hữu ích để thực hiện điều này có thể thực hiện được).
• Haskell, một ngôn ngữ lập trình chức năng thuần túy, cho phép xác định bất kỳ toán tử nào chỉ bao gồm dấu câu và cho phép bạn cung cấp một mức độ cố định (có sẵn 10) và tính kết hợp. Toán tử ternary vv có thể được tạo ra từ các toán tử nhị phân và các hàm bậc cao hơn.
• Agda, một ngôn ngữ lập trình được gõ phụ thuộc, cực kỳ linh hoạt với các toán tử (giấy ở đây ) cho phép cả định nghĩa if-then và if-then-other được định nghĩa là các toán tử trong cùng một chương trình, nhưng trình phân tích cú pháp, trình phân tích cú pháp và trình đánh giá của nó đều được kết hợp mạnh mẽ kết quả là

Một trong những lý do chính khiến các nhà khai thác tùy chỉnh không được khuyến khích là vì sau đó bất kỳ nhà khai thác nào cũng có thể có nghĩa / có thể làm bất cứ điều gì.

Ví dụ cstream, nhiều chỉ trích quá tải trái ca.

Khi một ngôn ngữ cho phép người vận hành quá tải, thường có một sự khuyến khích để giữ cho hành vi của người vận hành tương tự như hành vi cơ sở để tránh nhầm lẫn.

Ngoài ra các toán tử do người dùng định nghĩa làm cho việc phân tích cú pháp khó khăn hơn nhiều, đặc biệt là khi cũng có các quy tắc tùy chọn tùy chỉnh.

Chúng tôi không sử dụng các toán tử do người dùng định nghĩa cho cùng một lý do chúng tôi không sử dụng các từ do người dùng xác định. Không ai gọi chức năng của họ là "sworp". Cách duy nhất để truyền đạt suy nghĩ của bạn cho người khác là sử dụng ngôn ngữ chung. Và điều đó có nghĩa là cả hai từ và dấu hiệu (toán tử) phải được biết đến với xã hội mà bạn đang viết mã của mình.

Do đó, các toán tử mà bạn thấy được sử dụng trong các ngôn ngữ lập trình là những toán tử chúng ta đã được dạy ở trường (số học) hoặc các toán tử đã được thiết lập trong cộng đồng lập trình, như các toán tử boolean nói.

Đối với các ngôn ngữ hỗ trợ quá tải như vậy: Scala thực sự, theo cách tốt hơn và tốt hơn có thể C ++. Hầu hết các ký tự có thể được sử dụng trong tên hàm, vì vậy bạn có thể xác định các toán tử như! + * = ++, nếu bạn muốn. Có hỗ trợ tích hợp cho infix (cho tất cả các hàm lấy một đối số). Tôi nghĩ bạn cũng có thể định nghĩa tính kết hợp của các chức năng đó. Tuy nhiên, bạn không thể xác định quyền ưu tiên (chỉ với các thủ thuật xấu, xem tại đây ).

Một điều chưa được đề cập đến là trường hợp của Smalltalk, nơi mọi thứ (bao gồm cả các nhà khai thác) là một tin nhắn gửi. "Toán tử" thích +, |v.v. thực sự là các phương thức đơn nguyên.

Tất cả các phương thức có thể được ghi đè, a + bcó nghĩa là cộng số nguyên nếu avà bđều là số nguyên và có nghĩa là phép cộng nếu cả hai đều OrderedCollectionlà s.

Không có quy tắc ưu tiên, vì đây chỉ là các cuộc gọi phương thức. Điều này có một ý nghĩa quan trọng đối với ký hiệu toán học tiêu chuẩn: 3 + 4 * 5phương tiện (3 + 4) * 5, không 3 + (4 * 5).

.

Bạn đang chiến đấu chống lại hai điều ở đây:

1. Tại sao các nhà khai thác tồn tại trong các ngôn ngữ ở nơi đầu tiên?
2. Đức tính của các nhà khai thác trên các chức năng / phương pháp là gì?

Trong hầu hết các ngôn ngữ, các toán tử không thực sự được thực hiện như các hàm đơn giản. Chúng có thể có một số giàn giáo chức năng, nhưng trình biên dịch / thời gian chạy nhận thức rõ ràng về ý nghĩa ngữ nghĩa của chúng và cách dịch chúng hiệu quả sang mã máy. Điều này đúng hơn nhiều so với các hàm dựng sẵn (đó là lý do tại sao hầu hết các triển khai cũng không bao gồm tất cả các hàm gọi qua chức năng trong quá trình thực hiện của chúng). Hầu hết các toán tử là trừu tượng mức cao hơn trên các hướng dẫn nguyên thủy được tìm thấy trong CPU (đó là một phần lý do tại sao hầu hết các toán tử là số học, boolean hoặc bitwise). Bạn có thể mô hình hóa chúng thành các hàm "đặc biệt" (gọi chúng là "nguyên thủy" hoặc "nội dung" hoặc "nguyên gốc" hoặc bất cứ thứ gì), nhưng để làm điều đó một cách khái quát đòi hỏi một bộ ngữ nghĩa rất mạnh mẽ để xác định các hàm đặc biệt đó. Cách khác là có các toán tử dựng sẵn trông giống như các toán tử do người dùng định nghĩa, nhưng nếu không thì gọi các đường dẫn đặc biệt trong trình biên dịch. Đó là câu trả lời cho câu hỏi thứ hai ...

Ngoài vấn đề dịch máy tôi đã đề cập ở trên, ở cấp độ cú pháp, các toán tử không thực sự khác biệt với các chức năng. Các đặc điểm phân biệt của chúng có xu hướng là chúng ngắn gọn và tượng trưng, ​​gợi ý về một đặc điểm bổ sung quan trọng mà chúng phải có ích: chúng phải có ý nghĩa / ngữ nghĩa được hiểu rộng rãi cho các nhà phát triển. Các biểu tượng ngắn không truyền tải nhiều ý nghĩa trừ khi đó là bàn tay ngắn cho một tập hợp các ngữ nghĩa đã được hiểu. Điều đó làm cho các toán tử do người dùng định nghĩa vốn không có ích, vì bản chất của chúng, chúng không được hiểu rộng rãi như vậy. Chúng có ý nghĩa nhiều như một hoặc hai tên hàm chữ cái.

Quá tải toán tử của C ++ cung cấp mảnh đất màu mỡ để kiểm tra điều này. Hầu hết quá trình "lạm dụng" của nhà điều hành xuất hiện dưới dạng quá tải phá vỡ một số hợp đồng ngữ nghĩa được hiểu rộng rãi (một ví dụ cổ điển là sự quá tải của toán tử + sao cho a + b! = B + a hoặc trong đó + sửa đổi một trong hai Toán hạng).

Nếu bạn nhìn vào Smalltalk, công cụ cho phép nạp chồng toán tử và toán tử do người dùng xác định, bạn có thể thấy ngôn ngữ có thể thực hiện như thế nào và mức độ hữu dụng của nó. Trong Smalltalk, các toán tử chỉ là các phương thức có các thuộc tính cú pháp khác nhau (cụ thể, chúng được mã hóa dưới dạng nhị phân infix). Ngôn ngữ sử dụng "phương thức nguyên thủy" cho các phương thức và toán tử tăng tốc đặc biệt. Bạn thấy rằng rất ít nếu có bất kỳ toán tử do người dùng xác định nào được tạo và khi có, chúng có xu hướng không được sử dụng nhiều như tác giả có thể dự định sử dụng chúng. Ngay cả tương đương với quá tải toán tử là hiếm, bởi vì phần lớn là mất mạng để định nghĩa hàm mới là toán tử thay vì phương thức, vì cái sau cho phép biểu thị ngữ nghĩa của hàm.

Tôi luôn thấy quá tải toán tử trong C ++ là lối tắt thuận tiện cho nhóm nhà phát triển đơn lẻ, nhưng điều này gây ra tất cả các loại nhầm lẫn trong thời gian dài chỉ vì các cuộc gọi phương thức bị "ẩn" theo cách không dễ dàng để các công cụ như doxygen chọn ra và mọi người cần hiểu các thành ngữ để sử dụng chúng đúng cách.

Đôi khi, rất khó để có ý nghĩa hơn bạn mong đợi, thậm chí. Ngày xưa, trong một dự án C ++ đa nền tảng lớn, tôi đã quyết định nên bình thường hóa cách các đường dẫn được xây dựng bằng cách tạo một FilePathđối tượng (tương tự như Fileđối tượng Java ), có toán tử / được sử dụng để ghép nối một đối tượng khác phần đường dẫn trên đó (vì vậy bạn có thể làm một cái gì đó như thế File::getHomeDir()/"foo"/"bar"và nó sẽ làm điều đúng trên tất cả các nền tảng được hỗ trợ của chúng tôi). Tất cả những người nhìn thấy nó về cơ bản sẽ nói, "Cái quái gì vậy? Phân chia chuỗi? ... Ồ, thật dễ thương, nhưng tôi không tin nó sẽ làm điều đúng đắn."

Tương tự, có rất nhiều trường hợp trong lập trình đồ họa hoặc các lĩnh vực khác trong đó toán học vectơ / ma trận xảy ra rất nhiều trong đó thật hấp dẫn để làm những việc như Ma trận * Ma trận, Vector * Vector (chấm), Vector% Vector (chéo), Ma trận * Vector ( biến đổi ma trận), Ma trận ^ Vector (biến đổi ma trận trường hợp đặc biệt bỏ qua tọa độ đồng nhất - hữu ích cho các quy tắc bề mặt), v.v., nhưng trong khi nó tiết kiệm một chút thời gian phân tích cú pháp cho người viết thư viện toán học vectơ, nó chỉ kết thúc gây nhầm lẫn vấn đề nhiều hơn cho người khác. Nó không đáng

Quá tải toán tử là một ý tưởng tồi vì cùng một lý do rằng quá tải phương thức là một ý tưởng tồi: cùng một biểu tượng trên màn hình sẽ có ý nghĩa khác nhau tùy thuộc vào những gì xung quanh nó. Điều này làm cho nó khó khăn hơn cho việc đọc thông thường.

Vì khả năng đọc là một khía cạnh quan trọng của khả năng bảo trì, bạn nên luôn luôn tránh quá tải (trừ một số trường hợp rất đặc biệt). Sẽ tốt hơn nhiều cho mỗi ký hiệu (cho dù là toán tử hoặc mã định danh chữ số) có một ý nghĩa duy nhất đứng riêng.

Để minh họa: khi đọc mã không quen thuộc, nếu bạn gặp một mã định danh chữ và số mới mà bạn không biết, ít nhất bạn có lợi thế là bạn biết bạn không biết nó. Sau đó bạn có thể đi tìm nó. Tuy nhiên, nếu bạn thấy một mã định danh hoặc toán tử phổ biến mà bạn biết ý nghĩa của nó, thì bạn sẽ ít nhận thấy rằng nó thực sự đã bị quá tải để có một ý nghĩa hoàn toàn khác. Để biết những toán tử nào đã bị quá tải (trong một cơ sở mã đã sử dụng quá tải), bạn sẽ cần có kiến ​​thức làm việc về mã hoàn chỉnh, ngay cả khi bạn chỉ muốn đọc một phần nhỏ của nó. Điều này sẽ gây khó khăn cho việc đưa các nhà phát triển mới tăng tốc mã đó và không thể đưa mọi người vào một công việc nhỏ. Điều này có thể tốt cho bảo mật công việc lập trình viên, nhưng nếu bạn chịu trách nhiệm cho sự thành công của cơ sở mã, bạn nên tránh thực hành này bằng mọi giá.

Bởi vì các toán tử có kích thước nhỏ, các toán tử quá tải sẽ cho phép mã dày đặc hơn, nhưng làm cho mã dày đặc không phải là một lợi ích thực sự. Một dòng có hai lần logic mất gấp đôi thời gian để đọc. Trình biên dịch không quan tâm. Vấn đề duy nhất là khả năng đọc của con người. Vì làm cho mã nhỏ gọn không tăng cường khả năng đọc, không có lợi ích thực sự cho sự gọn nhẹ. Hãy tiếp tục và chiếm dung lượng và cung cấp cho các hoạt động duy nhất một mã định danh duy nhất và mã của bạn sẽ thành công hơn về lâu dài.

Những khó khăn kỹ thuật để xử lý quyền ưu tiên và phân tích cú pháp phức tạp được đặt sang một bên, tôi nghĩ rằng có một vài khía cạnh của ngôn ngữ lập trình là gì phải được xem xét.

Các toán tử thường là các cấu trúc logic ngắn được xác định rõ và được ghi lại bằng ngôn ngữ cốt lõi (so sánh, gán ..). Họ cũng thường khó hiểu mà không cần tài liệu (so sánh a^bvới xor(a,b)ví dụ). Có một số lượng toán tử khá hạn chế thực sự có thể có ý nghĩa trong lập trình bình thường (>, <, =, + vv ..).

Ý tưởng của tôi là tốt hơn là nên bám vào một tập hợp các toán tử được xác định rõ bằng ngôn ngữ - sau đó cho phép toán tử nạp chồng các toán tử đó (đưa ra một khuyến nghị mềm rằng các toán tử nên làm điều tương tự, nhưng với kiểu dữ liệu tùy chỉnh).

Các trường hợp sử dụng của bạn ~và |thực sự sẽ có thể với quá tải toán tử đơn giản (C #, C ++, v.v.). DSL là một khu vực sử dụng hợp lệ, nhưng có lẽ là một trong những khu vực hợp lệ duy nhất (theo quan điểm của tôi). Tuy nhiên, tôi nghĩ rằng có những công cụ tốt hơn để tạo ra các ngôn ngữ mới bên trong. Thực hiện một ngôn ngữ DSL thực sự trong một ngôn ngữ khác không phải là khó khăn bằng cách sử dụng bất kỳ công cụ biên dịch trình biên dịch nào. Tương tự với "đối số LUA mở rộng". Một ngôn ngữ rất có thể được xác định chủ yếu để giải quyết vấn đề theo một cách cụ thể, không phải là nền tảng cho các ngôn ngữ phụ (ngoại lệ tồn tại).

Một yếu tố khác cho nó là không phải lúc nào cũng dễ dàng xác định một hoạt động với các toán tử có sẵn. Ý tôi là, vâng, đối với bất kỳ loại số nào, toán tử '*' có thể có ý nghĩa và thường được triển khai bằng ngôn ngữ hoặc trong các mô-đun hiện có. Nhưng trong trường hợp các lớp phức tạp điển hình mà bạn cần xác định (những thứ như ShipingAddress, WindowManager, ObjectDimensions, PlayerCharacter, v.v.) thì hành vi đó không rõ ràng ... Việc thêm hoặc bớt một số vào Địa chỉ nghĩa là gì? Nhân hai địa chỉ?

Chắc chắn, bạn có thể định nghĩa rằng việc thêm một chuỗi vào lớp ShippingAddress có nghĩa là một hoạt động tùy chỉnh như "thay thế dòng 1 trong địa chỉ" (thay vì chức năng "setLine1") và thêm một số là "thay thế mã zip" (thay vì "setZipCode") , nhưng sau đó mã không dễ đọc và khó hiểu. Chúng tôi thường nghĩ rằng toán tử được sử dụng trong các loại / lớp cơ bản, vì hành vi của chúng là trực quan, rõ ràng và nhất quán (ít nhất là khi bạn đã quen với ngôn ngữ này). Hãy suy nghĩ trong các loại như Integer, String, ComplexNumbers, v.v.

Vì vậy, ngay cả khi việc xác định toán tử có thể rất hữu ích trong một số trường hợp cụ thể, thì việc triển khai trong thế giới thực của chúng khá hạn chế, vì 99% các trường hợp đó sẽ là một chiến thắng rõ ràng đã được thực hiện trong gói ngôn ngữ cơ bản.