已经在“子”范围内用于表示其他内容 [英] already used in a 'child' scope to denote something else
问题描述
{
int i = 2;
}
int i = 1;
从
声明的那一刻起，父母的背景中没有定义我。那么问题是什么？他们告诉我们他们追求语言
简单。规则不要在相同的
上下文中多次定义变量是自然的，也是最简单的。所有普通语言都遵守它
因此。通过注入更多的barrieres来过度复杂的语法是一条路径
，而不是简单。普通地方的另一个障碍是在C＃中引入了
，无缘无故阻挡了堕落。在开关中 - 功能
有时可能非常有用。 C＃设计师在保护我们自然而然地做事情上表现出了一些过度的热情，b / b
方式。
给一个傻瓜绳子，他就会自己上吊。
{
int i = 2;
}
int i = 1;
There is no ''i'' defined in the ''parent'' context from the moment of
declaration on. So what is the problem? They tell us they pursue language
simplicity. The rule "do not define a variable more than once in the same
context" is natural, and simplest therefore. All normal languages obey it
therefore. Overcomplicating a grammar by injecting more barrieres is a path
right away from simplicity. Another obstacle at the plain place introduced
in C# for no reason is blocking "fall throughs" in switch -- the feature
wich can be very useful sometimes. C# designers demonstrate some excessive
zeal on ''protecting'' us from doing things naturally, going strightforward
ways.
"Give a fool rope enough and he''ll hang himself."
推荐答案
6月8日上午7:59，valentin tihomirov" < V_tihomi ... @ best.eewrote：
On Jun 8, 7:59 am, "valentin tihomirov" <V_tihomi...@best.eewrote:
{
int i = 2;
}
int i = 1;
从'父母''上下文中没有定义''i'从
开始
声明。那么问题是什么？
{
int i = 2;
}
int i = 1;
There is no ''i'' defined in the ''parent'' context from the moment of
declaration on. So what is the problem?
>来自规范的第10.7节：
>From section 10.7 of the spec:
< quote>
在local-variable-declaration中声明的局部变量的范围
是声明发生的块。
< / quote> ;
换句话说，外部变量i的范围包括声明之前块的
部分。然后有一个额外的规则：
< quote>
在局部变量的范围内，它是一个编译时错误
在局部变量的
local-variable-declarator之前的文本位置引用局部变量。
< / quote>
理由在说明书中给出：
< quote>
注：范围界定局部变量的规则旨在保证表达式上下文中使用的名称的含义始终与块中的相同。
。如果局部变量的范围仅从其声明到块的末尾扩展
，那么在上面的示例
中，第一个赋值将分配给实例变量和
第二个赋值将分配给局部变量。在某些情况下，但在上面的示例中，如果稍后重新排列块的语句，则可能导致编译 -
时间错误。
< / quote>
<quote>
The scope of a local variable declared in a local-variable-declaration
is the block in which the declaration occurs.
</quote>
In other words, the "outer" variable i has scope which includes the
part of the block before it was declared. There''s then an extra rule:
<quote>
Within the scope of a local variable, it is a compile-time error to
refer to the local variable in a textual position that precedes the
local-variable-declarator of the local variable.
</quote>
The rationale is given in notes of the spec:
<quote>
Note: The scoping rules for local variables are designed to guarantee
that the meaning of a name used in an expression context is always the
same within a block. If the scope of a local variable were to extend
only from its declaration to the end of the block, then in the example
above, the first assignment would assign to the instance variable and
the second assignment would assign to the local variable. In certain
situations but not in the exampe above, this could lead to a compile-
time error if the statements of the block were later to be rearranged.
</quote>
他们告诉我们他们追求语言
简单。规则不要在相同的
上下文中多次定义变量是自然的，也是最简单的。所有普通语言都遵守它
因此。通过注入更多的barrieres来过度复杂的语法是一条路径
，而不是简单。
They tell us they pursue language
simplicity. The rule "do not define a variable more than once in the same
context" is natural, and simplest therefore. All normal languages obey it
therefore. Overcomplicating a grammar by injecting more barrieres is a path
right away from simplicity.
普通地方的另一个障碍是在C＃中引入了无限制的
阻止堕落在开关中 - 功能
有时可能非常有用。
Another obstacle at the plain place introduced
in C# for no reason is blocking "fall throughs" in switch -- the feature
wich can be very useful sometimes.
非常有用，有时候是故意的，但也非常痛苦的时候
你不想要它并且意外地拥有它。请注意，您*可以*使用
单个块的多个案例，您不能没有休息时间的情况/代码/案例/
代码。 />
我怀疑在和C一起工作的时候，当我忘记包含休息时间时，我会遇到更多次，而不是我故意想要的时间
通过。
一般来说，switch语句的设计并不是很好 -
它可以回到C太多了，IMO 。我宁愿看到一些情况
需要一套额外的括号，然后你可以使用
有明确的继续状态。而不是因为没有突破而休息。
所以是的，我同意开关并不好 - 但是取消对
的限制以防止坠落让它变得更糟，IMO。
Very useful sometimes when it''s deliberate, but also very painful when
you don''t want it and accidentally have it. Note that you *can* use
multiple cases for a single block, you just can''t have case/code/case/
code without a break.
I suspect that when working with C, I ran into more times when I
forgot to include the break than times when I deliberately wanted to
fall through.
The switch statement isn''t very nicely designed in general, however -
it harks back to C too much, IMO. I would rather have seen cases
require an extra set of braces, and for fallthrough you could then
have an explicit "continue" instead of a break for non-fallthrough.
So yes, I agree that switch isn''t great - but taking away the
restriction against fallthrough would make it even worse, IMO.
C＃设计师在保护我们自然做事方面表现出一些过度的热情b $ b热情strightforward
方式。
C# designers demonstrate some excessive
zeal on ''protecting'' us from doing things naturally, going strightforward
ways.
嗯，我对这两个决定都很满意。
Well, I''m happy with both of these decisions.
傻瓜绳子够了，他会自己上吊。
"Give a fool rope enough and he''ll hang himself."
True。你提供的绳索越少，他就越愚蠢
虽然......
Jon
True. The less rope you provide, the more foolish he has to be
though...
Jon
换句话说，外部是指外部。变量i的范围包括
In other words, the "outer" variable i has scope which includes the
声明之前块的一部分。然后有一个额外的规则：
part of the block before it was declared. There''s then an extra rule:
事实上，语句是一个接一个地执行的。
这是事实一个指令块作为一个语句执行。事实上，允许延迟的
声明的imerative语言中的变量仅在过去的声明中可见。获取这些基本的
很重要，每个人都知道在块内部看不到块块变量已经过了块，并且块内部
变量在块之后不可见。其他考虑因素是
irrationale。
It is a fact that statements are executed seqientially, one after another.
It is truth that a block of instructions is executed as one statement. It is
truth that the variables in the imerative languages, which allow deferred
declarations, are visible only past declaration. Acquiring these basic
matters, everybody understands that the parent block variables declared past
the block are not visible inside the block and that the block internal
variables are not visible past the block. The other considerations are
irrationale.
< quote>在某些
情况下但不在例子中如果稍后重新安排块的语句，则可能导致编译时间错误。
< / quote>
<quote>In certain
situations but not in the exampe above, this could lead to a compile-
time error if the statements of the block were later to be rearranged.
</quote>
重新排列代码总是会产生错误。这个论点是否给我权力
来推断任意规则？
Rearranging code always can yeild errors. Does this argument give me power
to infer arbitrary rules?
>他们告诉我们他们追求语言简单。规则不要在相同的
上下文中多次定义变量。是自然的，也是最简单的。因此，所有正常语言都遵守它。通过注入更多barrieres来过度复杂语法是一种远离简单的道路。
>They tell us they pursue language
simplicity. The rule "do not define a variable more than once in the same
context" is natural, and simplest therefore. All normal languages obey it
therefore. Overcomplicating a grammar by injecting more barrieres is a
path
right away from simplicity.
>普通地方的另一个障碍是无条件地在C＃中引入
阻止堕落在开关 - 功能
有时可能非常有用。
>Another obstacle at the plain place introduced
in C# for no reason is blocking "fall throughs" in switch -- the feature
wich can be very useful sometimes.
非常有用，有时当它是故意的，但也非常痛苦的时候
你不想要它并且意外地拥有它。请注意，您*可以*使用
单个块的多个案例，您不能没有休息时间的情况/代码/案例/
代码。 />
我怀疑在和C一起工作的时候，当我忘记包含休息时间时，我会遇到更多次，而不是我故意想要的时间
掉头。
Very useful sometimes when it''s deliberate, but also very painful when
you don''t want it and accidentally have it. Note that you *can* use
multiple cases for a single block, you just can''t have case/code/case/
code without a break.
I suspect that when working with C, I ran into more times when I
forgot to include the break than times when I deliberately wanted to
fall through.
我认为程序员应该知道的第一件事是指令执行的序列
。通常情况下，这些陈述依次是
。我们是否应该在每一个
语句之后放置一个明确的分支，以避免自然的跌倒？通过禁令不会使您免受可能造成的各种错误的影响，包括
错误的分支。它只是推断了相当数量的代码，而不必要的是
。你应该考虑避免编程是安全的。我怀疑
要求堆积语法盐的负荷可以提高无意识人员产生的代码质量。
I suppose that the first thing the programmers should know is the sequence
of instruction execution. Normally, the statements are eveluated
sequentially. Should we put an explicit branch after each and every
statement to avoid the natural "fall through"? The fallthrough ban does not
save you from the infinite kinds of errors you still can make, including
wrong branching. It just infers a fair amount of code where it is
unnecessariy. You should consider avoid programming be safe. I doubt that
the requirement to pile up the loads of syntactic salt improves the quality
of code the unconscious people produce.
6月8日下午1:16，valentin tihomirov < V_tihomi ... @ best.eewrote：
< snip>
On Jun 8, 1:16 pm, "valentin tihomirov" <V_tihomi...@best.eewrote:
<snip>
重新排列代码总是会产生错误。这个论点是否给了我力量
来推断任意规则？
Rearranging code always can yeild errors. Does this argument give me power
to infer arbitrary rules?
我只是告诉你语言设计师给出的理由。
就个人而言，我没有遇到任何问题 - 我发现它倾向于使
代码更具可读性，无论如何在这个
类型的情况下给变量赋予不同的名称。我不能说经常让我感到困扰 - 它不是一件紧身衣，不是吗？
I was just giving you the reasons the language designers gave.
Personally, I don''t have a problem with it - I find it tends to make
the code more readable to give the variables different names in this
kind of case anyway. I can''t say it''s bothered me that often - it''s
hardly a straitjacket, is it?
我怀疑在和C一起工作的时候，当我故意忘记包含休息时间时，我会遇到更多次，而不是我故意想要的时间
跌倒了。
I suspect that when working with C, I ran into more times when I
forgot to include the break than times when I deliberately wanted to
fall through.
我认为程序员应该知道的第一件事是指令执行的序列
。
I suppose that the first thing the programmers should know is the sequence
of instruction execution.
这不是了解规则的问题，而是
规则是否容易让你犯错误。
每当我忘记休息时，这只是一个简单的问题，而不是无法理解代码会做什么。
不，这不会阻止每一个错误。是的，它阻止某些方式工作。但是，我认为它比它更有帮助，这就是为什么我赞成它。
关于你改变主题，我会反驳：继续吧。使用C＃停止
。这将阻止你受到其规则的阻碍。
说真的，如果你不喜欢这么多语言的设计决定，为什么
使用它呢？
Jon
It''s not a matter of knowing the rules, it''s a matter of whether the
rules let you easily make mistakes.
Every time I forgot to put a break in, it was a simple matter of
forgetfulness, not a failure to understand what the code would do.
No, this won''t prevent every mistake. Yes, it prevents certain ways of
working. However, I believe it helps more than it hinders, which is
why I''m in favour of it.
Regarding your change of subject line, I would retort: "Go ahead. Stop
using C#. That will stop you from being hindered by its rules."
Seriously, if you dislike so many design decisions of a language, why
use it?
Jon
这篇关于已经在“子”范围内用于表示其他内容的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
