Category talk:Go: Difference between revisions
→In general, non-solutions: Opinions and positions.
(→Exceptions/Catch an exception thrown in a nested call: Task may require modification) |
(→In general, non-solutions: Opinions and positions.) |
||
Line 14:
* Solutions using subpackages of exp or go. Exp is for experimental and I don't think we'd be doing RC readers any favors by showing solutions based on these packages. The subpackages of go are not experimental, but they are pieces of the implementation of Go. That is, they are components for writing a language, not using one. Unless the task is about implementing a language, again, I don't think we would be doing RC readers any favor by implementing our own flavor of Go just to allow a task solution.
: When I introduce people to Rosetta Code, they often want to know how strict the rules are for the nature of task solutions. I'll generally say something like, "if that's how you would do it in that language, then that's how you would do it in that language." I don't tend to condone removal of examples which successfully implement tasks; if there's a better technique, I'd like to see that way shown instead or as well. This helps demonstrate the flexibility of a language, and also serves to avoid edit wars between users with different, strong opinions. If there are significant downsides, or if an example is a last-resort solution, then it's going to be far more useful and helpful for an end-user to see that explained. I.e. in the case of C++, "this is how you use '''malloc'''. You shouldn't do this; it's more trouble than it's worth, and will lead you to bad habits. You should use '''new''' instead." --[[User:Short Circuit|Michael Mol]] 02:43, 30 April 2011 (UTC)
* Solutions that excessively stretch the interpretation of the task. I know, it's usually a total judgement call. I've written several solutions that stretch interpretations pretty far. If you run across something like this and have strong feelings about it, remove the solution, mark the task omit, and then explain your reasoning here. The decision about how much stretching to allow sould be based heavily on the task wording. If the task description is very specific, not much stretching should be allowed. If the task says “do your best to achieve the end result,” then creative interpretations are probably in order.
: In general, I'd rather see a best-effort work-alike solution for language A to task B, than no solution for language A, so long as there is an explanation of the caveats. Personally, I find that helps me understand language A's peculiarities better, and I expect the same would be true for others. --[[User:Short Circuit|Michael Mol]] 02:43, 30 April 2011 (UTC)
===Add a variable to a class instance at runtime===
| |||