wiki: fix typos
This PR fixes a few typos I spotted in various wiki pages.
Change-Id: I64109ccabdc5b3301f5dcc713fae3773a70bf296
GitHub-Last-Rev: af2b44ed694db06ed0694e13796c947157953823
GitHub-Pull-Request: golang/wiki#5
Reviewed-on: https://go-review.googlesource.com/c/wiki/+/552636
Auto-Submit: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Matt Layher <mdlayher@gmail.com>
diff --git a/Books.md b/Books.md
index b406269..f21506c 100644
--- a/Books.md
+++ b/Books.md
@@ -966,7 +966,7 @@
* Reference: http://www.acornpub.co.kr/book/go-language-minna
* **Go Cookbook**
- * Author: Aaron Torres; transalted by Sangsik Lee
+ * Author: Aaron Torres; translated by Sangsik Lee
* Publication Date: December 2017
* ISBN: 979-1-16175-088-0
* Reference: http://www.acornpub.co.kr/book/go-cookbook
diff --git a/Go2GenericsFeedback.md b/Go2GenericsFeedback.md
index 3521c83..596bfdd 100644
--- a/Go2GenericsFeedback.md
+++ b/Go2GenericsFeedback.md
@@ -41,7 +41,7 @@
- Gustavo Bittencourt, "[Contracts only for Generic Types](https://gist.github.com/gbitten/9faf20886728d3750e106e352c31f0e9)", March 2019
-- David Heuschmann, "[Problems With Using Parantheses for Type Argument Lists](https://gist.github.com/dddent/6e4a7490f80cb427c0e910ebca5c3468)", February 2019
+- David Heuschmann, "[Problems With Using Parentheses for Type Argument Lists](https://gist.github.com/dddent/6e4a7490f80cb427c0e910ebca5c3468)", February 2019
- Gustavo Bittencourt, "[Contract with methods](https://gist.github.com/gbitten/6e17ef81be876d70f624c711f5a3b0e2)", February 2019
@@ -277,7 +277,7 @@
- DeedleFake: I completely agree with the arguments against operator overloading, and I'm quite glad overall that Go doesn't have it, but I also think that the inability to resolve the difference between `a == b` and `a.Equals(b)` via a contract is the biggest problem with the draft design as it currently stands. It means that you'd still wind up writing multiple functions for a fair number of things. Try writing a binary tree, for example. Should you use a contract with `t < t` or `t.Less(t)`? For a sum function, should you use `t + t` or `t.Plus(t)`? I definitely want a solution that doesn't involve operator overloading, though. Maybe there could be a way to specify an adapter that basically says `if a type T, which satisfies contract A but not B, is used for a parameter constrained by contract B, apply this to it in order to get it to satisfy contract B`. Contract B could require a `Plus()` method, for example, while contract A requires the use of `+`, so the adapter automatically attaches a user-specified `Plus()` method to `T` for the duration of its use under that contract.
- Something that might work with this proposal is an `equal(a, b)` builtin that uses `a.Equals(b)` if it exists and `a == b` otherwise, failing to compile if the type is incomparable (and likewise for other operators). It's too weird to seriously consider but it would work with contracts and allow dodging the asymmetry between types that have operators and those that cannot without introducing operator overloading —jimmyfrasche
- Another idea would be explicitly overloadable operators: `a + b` is not overloadable, but `a [+] b` can be overloaded. It will use normal + for primitive types, but will use `Operator+()` etc. for objects if those are present. I really do think that generics without some sane form of operator overloading or something like it are a lot less useful to the point that you might as well not even do it. -Adam Ierymenko (original poster)
- - Ian Denhardt: DeedleFake outlines the problems with not having operator overloading well I. I think proposals involving making the overloading "loud" are the wrong idea; instead, we should limit which operators can be overloaded to operators which satisfy these critera:
+ - Ian Denhardt: DeedleFake outlines the problems with not having operator overloading well I. I think proposals involving making the overloading "loud" are the wrong idea; instead, we should limit which operators can be overloaded to operators which satisfy these criteria:
1. The operator's semantics can be understood as a method call. Most of the operators on numbers pass this test; `big.Add` is still addition in the sense that we know it from int32, uint64 etc. Examples of operators that fail this test are `&&` and `||`; these are short circuting, which no function or method can replicate. They are fundamentally not methods, no matter how you look at them, and should not be overridable by methods. I think operator overloading gets a bad rap in part because C++ allows you to override _everything_, including crazy stuff like the _comma operator_.
2. There should be clear use cases for overriding them. Again, arithmetic operators pass this test, along with `<` and friends. Pointer dereferencing passes the first test, but I'm having a hard time coming up with uses for "other types of pointers" that actually seem like a good idea. They are a bit more justifiable in C++, but garbage-collected pointers have basically got you covered.
3. The normal meaning of the operator should be something that is easy to reason about. For example, pointers are a gnarly source of bugs, and having the possibility that `*foo` is doing something other than reading from a memory address makes an already difficult debugging session that much harder. On the other hand, the possibility that `+` may be a call to `big.Add` is relatively self-contained, and unlikely to cause great confusion.
@@ -294,7 +294,7 @@
}
```
-- Tristan Colgate-McFarlane: After going back and forward for a while, I've come down in favour of the proposal largely as is. A limited syntax for contracts might be preferable, but I believe it should allow referencing specific fields (not just methods as some have proposed). If anything can be done to make compatible interface and contracts inter-use easier, that would also be nice (though I think maybe no additional specifications are needed. Lastly, I think it is worth considering deprecating interface types. Whilst drastic, contracts essentially also allow specifying behaviour. Any contract restrictions that limit that (such as refering to other types within the package), should probably be lifted. contracts appear to be a strict superset of interfaces, and I am generally against having two overlapping features. A tool to aide in writing interaces should also be considered.
+- Tristan Colgate-McFarlane: After going back and forward for a while, I've come down in favour of the proposal largely as is. A limited syntax for contracts might be preferable, but I believe it should allow referencing specific fields (not just methods as some have proposed). If anything can be done to make compatible interface and contracts inter-use easier, that would also be nice (though I think maybe no additional specifications are needed. Lastly, I think it is worth considering deprecating interface types. Whilst drastic, contracts essentially also allow specifying behaviour. Any contract restrictions that limit that (such as refering to other types within the package), should probably be lifted. contracts appear to be a strict superset of interfaces, and I am generally against having two overlapping features. A tool to aide in writing interfaces should also be considered.
- Patrick Smith: We might consider requiring the type keyword when defining methods on generic types. This makes the code a little more verbose, but clearer and more consistent (now type parameters are always preceded by the type keyword).
diff --git a/GoUsers.md b/GoUsers.md
index 2f96497..aa8d2b7 100644
--- a/GoUsers.md
+++ b/GoUsers.md
@@ -654,7 +654,7 @@
* [open market](https://openmarket.ir/) - best online home store.
* [ManaGroup](https://www.managroup.co/) - [github](https://github.com/managroup) Iranian Payment And Traveling Solution 💸✅🚀
* [Emji](https://emji.app/) - Emji is a new refined social networking platform aimed at simplicity and connectivity
- * [Clickyab](https://clickyab.com/) - Clickyab is diffrent online advertising & digital media agency
+ * [Clickyab](https://clickyab.com/) - Clickyab is different online advertising & digital media agency
* [Sazito](https://sazito.com/) - Sazito is multi-functional tools to build and manage your online store.
* [Aparat](http://www.aparat.com) -- Most popular video sharing platform in Iran
* [Asan Pardakht](http://asanpardakht.ir/) -- Pay Smarter. Pay Simpler. Pay Anywhere!
@@ -1304,7 +1304,7 @@
* [LINE MAN](https://lineman.line.me/) [Wongnai](https://www.wongnai.com)
* [NEXPIE](https://nexpie.com)
* [Odd-e Thailand](https://www.odd-e.com/th)
- * [ODDS](http://fb.me/oddsteam) - A group of people that belive tha software development should be fun. And we belive in continues improvement.
+ * [ODDS](http://fb.me/oddsteam) - A group of people that believe that software development should be fun. And we believe in continues improvement.
* [Omise](https://www.omise.co) - Payment gateway for Thailand.
* [Onedaycat](http://onedaycat.com)
* [Paiduaykanmai](https://www.facebook.com/paiduay.tech/)
diff --git a/Projects.md b/Projects.md
index 4958c27..80f7c15 100644
--- a/Projects.md
+++ b/Projects.md
@@ -1060,7 +1060,7 @@
* [syslog](https://github.com/ziutek/syslog) - With this package you can create your own syslog server with your own handlers for different kind of syslog messages
* [Tideland golib](https://github.com/tideland/golib) - Flexible logging
* [timber](https://github.com/ngmoco/timber) - Configurable Logger for Go
- * [ul](https://github.com/aletheia7/ul) - Provides macOS Sierra/OSX Unified Loggging functionality via cgo
+ * [ul](https://github.com/aletheia7/ul) - Provides macOS Sierra/OSX Unified Logging functionality via cgo
* [vlog](https://github.com/better0332/vlog) - Leveled log on std log for Go
### Machine Learning
diff --git a/TestComments.md b/TestComments.md
index 1e73577..a457a84 100644
--- a/TestComments.md
+++ b/TestComments.md
@@ -182,7 +182,7 @@
On a practical level, prefer calling `t.Error` over `t.Fatal`. When comparing
several different properties of a function's output, use `t.Error` for each of
-those comparisions.
+those comparisons.
`t.Fatal` is usually only appropriate when some piece of test setup fails,
without which you cannot run the test at all. In a table-driven test, `t.Fatal`
