- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
non-trivial shadowing
Sat, 2009-03-21, 20:02
Hi,
I have this code:
object WeirdCase { def xx(b: String, a: Boolean): String = { val b = 1 def a = b return "weird: " + a } def main(args: Array[String]) { print(xx("wow", true)) } }
The parameters of xx are being shadowed by the definitions inside. It is reasonable, a and b are declared within a block; but it is different from Java, where parameters seem to be declared in the body of the method.
So, maybe there should be some kind of warning regarding the cases of shadowing...
--
Thanks,
-Vlad
I have this code:
object WeirdCase { def xx(b: String, a: Boolean): String = { val b = 1 def a = b return "weird: " + a } def main(args: Array[String]) { print(xx("wow", true)) } }
The parameters of xx are being shadowed by the definitions inside. It is reasonable, a and b are declared within a block; but it is different from Java, where parameters seem to be declared in the body of the method.
So, maybe there should be some kind of warning regarding the cases of shadowing...
--
Thanks,
-Vlad
Sun, 2009-03-22, 21:57
#2
Re: non-trivial shadowing
On Sun, Mar 22, 2009 at 09:44:29AM -0700, Randall R Schulz wrote:
> It's made clear fairly early on in "Programming In Scala" that Scala
> works this way. See section 7.7 Variable Scope, page 135.
So what? I've known what the shadowing behavior is since I was still
being bounced on my pappy's knee, but that hasn't kept me wasting lots
and lots of time tracking down bugs that turned out to be a result of
accidental shadowing. I'm strongly in favor of a warning at least being
available, and it's on the long list of warnings I intend to implement
for some sort of -XLotsOfWarnings mode.
Sun, 2009-03-22, 22:07
#3
Re: non-trivial shadowing
On Sun, Mar 22, 2009 at 9:45 PM, Paul Phillips <paulp@improving.org> wrote:
On Sun, Mar 22, 2009 at 09:44:29AM -0700, Randall R Schulz wrote:
> It's made clear fairly early on in "Programming In Scala" that Scala
> works this way. See section 7.7 Variable Scope, page 135.
So what? I've known what the shadowing behavior is since I was still
being bounced on my pappy's knee, but that hasn't kept me wasting lots
and lots of time tracking down bugs that turned out to be a result of
accidental shadowing. I'm strongly in favor of a warning at least being
available, and it's on the long list of warnings I intend to implement
for some sort of -XLotsOfWarnings mode.
-XPedantic ;)
--
Paul Phillips | We must respect the other fellow's religion, but only
Everyman | in the sense and to the extent that we respect his
Empiricist | theory that his wife is beautiful and his children smart.
i'll ship a pulp | -- H. L. Mencken
--
Viktor Klang
Senior Systems Analyst
Sun, 2009-03-22, 22:37
#4
Re: non-trivial shadowing
Perhaps a @shadows annotation. I realise this may make people think
of guitar riffs while coding, but that's ok by me.
2009/3/22 Viktor Klang :
>
>
> On Sun, Mar 22, 2009 at 9:45 PM, Paul Phillips wrote:
>>
>> On Sun, Mar 22, 2009 at 09:44:29AM -0700, Randall R Schulz wrote:
>> > It's made clear fairly early on in "Programming In Scala" that Scala
>> > works this way. See section 7.7 Variable Scope, page 135.
>>
>> So what? I've known what the shadowing behavior is since I was still
>> being bounced on my pappy's knee, but that hasn't kept me wasting lots
>> and lots of time tracking down bugs that turned out to be a result of
>> accidental shadowing. I'm strongly in favor of a warning at least being
>> available, and it's on the long list of warnings I intend to implement
>> for some sort of -XLotsOfWarnings mode.
>
> -XPedantic ;)
>
>>
>> --
>> Paul Phillips | We must respect the other fellow's religion, but only
>> Everyman | in the sense and to the extent that we respect his
>> Empiricist | theory that his wife is beautiful and his children
>> smart.
>> i'll ship a pulp | -- H. L. Mencken
>
>
>
> --
> Viktor Klang
> Senior Systems Analyst
>
Mon, 2009-03-23, 02:17
#5
Re: non-trivial shadowing
On Sun, Mar 22, 2009 at 9:44 AM, Randall R Schulz <rschulz@sonic.net> wrote:
Page 135 shows an example with shadowing in a nested block. The example given to start this thread does not seem like quite the same thing to me. Is the block for defining a multiline function considered a nested block? I don't know. If it is, then you are correct. Either way, I don't see the point of allowing shadowing in this case. If I am not mistaken, the shadowing renders the arguments of the function completely inaccessible. What could possibly be the point of that? So why allow it?
Russ P.
On Saturday March 21 2009, Vlad Patryshev wrote:
> Hi,
> ...
>
> So, maybe there should be some kind of warning regarding the cases of
> shadowing...
It's made clear fairly early on in "Programming In Scala" that Scala
works this way. See section 7.7 Variable Scope, page 135.
Page 135 shows an example with shadowing in a nested block. The example given to start this thread does not seem like quite the same thing to me. Is the block for defining a multiline function considered a nested block? I don't know. If it is, then you are correct. Either way, I don't see the point of allowing shadowing in this case. If I am not mistaken, the shadowing renders the arguments of the function completely inaccessible. What could possibly be the point of that? So why allow it?
Russ P.
Mon, 2009-03-23, 09:47
#6
Re: non-trivial shadowing
On a related tangent, mutable method parameters could be handy. A
common and reasonable pattern in Java:
void fooBar(int x, int y)
{
x *= scale;
y *= scale;
blah
}
The closest in Scala without introducing extra identifiers:
def fooBar(x: Int, y: Int) = (x, y) * scale match { case (x, y) => blah }
I'd like the following to be valid:
def fooBar(var x: Int, var y: Int) = {
x *= scale
y *= scale
blah
}
But then I'd like to win the lottery, but never play it.
2009/3/23 Russ Paielli :
> On Sun, Mar 22, 2009 at 9:44 AM, Randall R Schulz wrote:
>>
>> On Saturday March 21 2009, Vlad Patryshev wrote:
>> > Hi,
>> > ...
>> >
>> > So, maybe there should be some kind of warning regarding the cases of
>> > shadowing...
>>
>> It's made clear fairly early on in "Programming In Scala" that Scala
>> works this way. See section 7.7 Variable Scope, page 135.
>
>
> Page 135 shows an example with shadowing in a nested block. The example
> given to start this thread does not seem like quite the same thing to me. Is
> the block for defining a multiline function considered a nested block? I
> don't know. If it is, then you are correct. Either way, I don't see the
> point of allowing shadowing in this case. If I am not mistaken, the
> shadowing renders the arguments of the function completely inaccessible.
> What could possibly be the point of that? So why allow it?
>
> Russ P.
>
>
Mon, 2009-03-23, 09:57
#7
Re: non-trivial shadowing
2009/3/23 Russ Paielli :
> On Sun, Mar 22, 2009 at 9:44 AM, Randall R Schulz wrote:
>>
>> On Saturday March 21 2009, Vlad Patryshev wrote:
>> > Hi,
>> > ...
>> >
>> > So, maybe there should be some kind of warning regarding the cases of
>> > shadowing...
>>
>> It's made clear fairly early on in "Programming In Scala" that Scala
>> works this way. See section 7.7 Variable Scope, page 135.
>
>
> Page 135 shows an example with shadowing in a nested block. The example
> given to start this thread does not seem like quite the same thing to me. Is
> the block for defining a multiline function considered a nested block? I
> don't know. If it is, then you are correct.
It is.
A function definition in Scala is simply of the form def
myFunction(...) = expression. Multiline functions just use a block
expression.
On Saturday March 21 2009, Vlad Patryshev wrote:
> Hi,
> ...
>
> So, maybe there should be some kind of warning regarding the cases of
> shadowing...
It's made clear fairly early on in "Programming In Scala" that Scala
works this way. See section 7.7 Variable Scope, page 135.
Randall Schulz