aboutsummaryrefslogtreecommitdiff
path: root/locale/pt/LC_MESSAGES/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generi...
diff options
context:
space:
mode:
authorEuAndreh <eu@euandre.org>2022-01-16 16:52:43 -0300
committerEuAndreh <eu@euandre.org>2022-01-16 16:52:43 -0300
commit1fc994f588dd9ef2ef8395e57e2492a6b4d730eb (patch)
treeab518e8c2c229ec60ba921adbf9897b25520b99d /locale/pt/LC_MESSAGES/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.po
parent.ignore: Remove unused file (diff)
downloadeuandre.org-1fc994f588dd9ef2ef8395e57e2492a6b4d730eb.tar.gz
euandre.org-1fc994f588dd9ef2ef8395e57e2492a6b4d730eb.tar.xz
git mv locale/ po/
Diffstat (limited to 'locale/pt/LC_MESSAGES/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.po')
-rw-r--r--locale/pt/LC_MESSAGES/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.po210
1 files changed, 0 insertions, 210 deletions
diff --git a/locale/pt/LC_MESSAGES/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.po b/locale/pt/LC_MESSAGES/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.po
deleted file mode 100644
index 6aa66a8..0000000
--- a/locale/pt/LC_MESSAGES/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.po
+++ /dev/null
@@ -1,210 +0,0 @@
-#
-msgid ""
-msgstr ""
-
-msgid ""
-"title: Common Lisp argument precedence order parameterization of a generic "
-"function"
-msgstr ""
-
-msgid "layout: post"
-msgstr ""
-
-msgid "lang: en"
-msgstr ""
-
-msgid ""
-"ref: common-lisp-argument-precedence-order-parameterization-of-a-generic-"
-"function"
-msgstr ""
-
-msgid ""
-"When CLOS dispatches a method, it picks the most specific method definition "
-"to the argument list:"
-msgstr ""
-
-msgid ""
-"\n"
-"* (defgeneric a-fn (x))\n"
-"#<STANDARD-GENERIC-FUNCTION A-FN (0) {5815ACB9}>\n"
-"\n"
-"* (defmethod a-fn (x) :default-method)\n"
-"#<STANDARD-METHOD A-FN (T) {581DB535}>\n"
-"\n"
-"* (defmethod a-fn ((x number)) :a-number)\n"
-"#<STANDARD-METHOD A-FN (NUMBER) {58241645}>\n"
-"\n"
-"* (defmethod a-fn ((x (eql 1))) :number-1)\n"
-"#<STANDARD-METHOD A-FN ((EQL 1)) {582A7D75}>\n"
-"\n"
-"* (a-fn nil)\n"
-":DEFAULT-METHOD\n"
-"\n"
-"* (a-fn \"1\")\n"
-":DEFAULT-METHOD\n"
-"\n"
-"* (a-fn 0)\n"
-":A-NUMBER\n"
-"\n"
-"* (a-fn 1)\n"
-":NUMBER-1\n"
-msgstr ""
-
-msgid ""
-"CLOS uses a similar logic when choosing the method from parent classes, when"
-" multiple ones are available:"
-msgstr ""
-
-msgid ""
-"* (defclass class-a () ())\n"
-"\n"
-"#<STANDARD-CLASS CLASS-A {583E0B25}>\n"
-"* (defclass class-b () ())\n"
-"\n"
-"#<STANDARD-CLASS CLASS-B {583E7F6D}>\n"
-"* (defgeneric another-fn (obj))\n"
-"\n"
-"#<STANDARD-GENERIC-FUNCTION ANOTHER-FN (0) {583DA749}>\n"
-"* (defmethod another-fn ((obj class-a)) :class-a)\n"
-"; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OBJ):\n"
-"; Compiling Top-Level Form:\n"
-"\n"
-"#<STANDARD-METHOD ANOTHER-FN (CLASS-A) {584523C5}>\n"
-"* (defmethod another-fn ((obj class-b)) :class-b)\n"
-"; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OBJ):\n"
-"; Compiling Top-Level Form:\n"
-"\n"
-"#<STANDARD-METHOD ANOTHER-FN (CLASS-B) {584B8895}>\n"
-msgstr ""
-
-msgid ""
-"Given the above definitions, when inheriting from `class-a` and `class-b`, "
-"the order of inheritance matters:"
-msgstr ""
-
-msgid ""
-"* (defclass class-a-coming-first (class-a class-b) ())\n"
-"#<STANDARD-CLASS CLASS-A-COMING-FIRST {584BE6AD}>\n"
-"\n"
-"* (defclass class-b-coming-first (class-b class-a) ())\n"
-"#<STANDARD-CLASS CLASS-B-COMING-FIRST {584C744D}>\n"
-"\n"
-"* (another-fn (make-instance 'class-a-coming-first))\n"
-":CLASS-A\n"
-"\n"
-"* (another-fn (make-instance 'class-b-coming-first))\n"
-":CLASS-B\n"
-msgstr ""
-
-msgid ""
-"Combining the order of inheritance with generic functions with multiple "
-"arguments, CLOS has to make a choice of how to pick a method given two "
-"competing definitions, and its default strategy is prioritizing from left to"
-" right:"
-msgstr ""
-
-msgid ""
-"* (defgeneric yet-another-fn (obj1 obj2))\n"
-"#<STANDARD-GENERIC-FUNCTION YET-ANOTHER-FN (0) {584D9EC9}>\n"
-"\n"
-"* (defmethod yet-another-fn ((obj1 class-a) obj2) :first-arg-specialized)\n"
-"#<STANDARD-METHOD YET-ANOTHER-FN (CLASS-A T) {5854269D}>\n"
-"\n"
-"* (defmethod yet-another-fn (obj1 (obj2 class-b)) :second-arg-specialized)\n"
-"#<STANDARD-METHOD YET-ANOTHER-FN (T CLASS-B) {585AAAAD}>\n"
-"\n"
-"* (yet-another-fn (make-instance 'class-a) (make-instance 'class-b))\n"
-":FIRST-ARG-SPECIALIZED\n"
-msgstr ""
-
-msgid ""
-"For that, we use the `:argument-precedence-order` option when declaring a "
-"generic function:"
-msgstr ""
-
-msgid ""
-"* (defgeneric yet-another-fn (obj1 obj2) (:argument-precedence-order obj2 obj1))\n"
-"#<STANDARD-GENERIC-FUNCTION YET-ANOTHER-FN (2) {584D9EC9}>\n"
-"\n"
-"* (yet-another-fn (make-instance 'class-a) (make-instance 'class-b))\n"
-":SECOND-ARG-SPECIALIZED\n"
-msgstr ""
-
-msgid ""
-"I liked that the `:argument-precedence-order` option exists. We shouldn't "
-"have to change the arguments from `(obj1 obj2)` to `(obj2 obj1)` just to "
-"make CLOS pick the method that we want. We can configure its default "
-"behaviour if desired, and keep the order of arguments however it best fits "
-"the generic function."
-msgstr ""
-
-msgid "Comparison with Clojure"
-msgstr ""
-
-msgid "Clojure has an equivalent, when using `defmulti`."
-msgstr ""
-
-msgid ""
-"Since when declaring a multi-method with `defmulti` we must define the "
-"dispatch function, Clojure uses it to pick the method definition. Since the "
-"dispatch function is required, there is no need for a default behaviour, "
-"such as left-to-right."
-msgstr ""
-
-msgid "Conclusion"
-msgstr ""
-
-msgid ""
-"Making the argument precedence order configurable for generic functions but "
-"not for class definitions makes a lot of sense."
-msgstr ""
-
-msgid ""
-"One shouldn't change the order of arguments of a generic function for the "
-"sake of tailoring it to the CLOS priority ranking algorithm, but doing it "
-"for a class definition is just fine."
-msgstr ""
-
-msgid "TIL."
-msgstr ""
-
-msgid ""
-"CLOS has to make a choice between the first and the second definition of "
-"`yet-another-fn`, but its choice is just a heuristic. What if we want the "
-"choice to be based on the second argument, instead of the first?"
-msgstr ""
-
-msgid ""
-"When declaring a class, we can choose the precedence order, and that is "
-"about it. But when defining a generic function, the order of arguments is "
-"more important to the function semantics, and the argument precedence being "
-"left-to-right is just the default behaviour."
-msgstr ""
-
-msgid "References"
-msgstr ""
-
-msgid ""
-"[Object-Oriented Programming in Common Lisp: A Programmer's Guide to "
-"CLOS](https://en.wikipedia.org/wiki/Object-"
-"Oriented_Programming_in_Common_Lisp), by Sonja E. Keene"
-msgstr ""
-
-msgid "date: 2021-04-24 2"
-msgstr ""
-
-#~ msgid "date: 2021-04-24"
-#~ msgstr ""
-
-#~ msgid ""
-#~ "CLOS has to make a choice between the first and the second definition of "
-#~ "`yet-another-fn`, but its choice is just a heuristic. What if we want to the"
-#~ " choice to be based on the second argument first?"
-#~ msgstr ""
-
-#~ msgid ""
-#~ "When declaring a class, we can choose the precedence order, and that is "
-#~ "about it. But when defining a generic function, the order of argumentws is "
-#~ "more important to the function semantics, and the argument precedence being "
-#~ "left-to-right is just the default behaviour."
-#~ msgstr ""