New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updated #27 for more LOL, less loll. #59
Updated #27 for more LOL, less loll. #59
Conversation
This is not a definitive version, except for the title. There are some style differences, like one-liners, reduced use of braces, and an implicit class to enhance StringBuilder. In a LOL vein, padTo is renamed pad2, and it is compared to the padTo out of the box. (It must be renamed for the extension method.) It seems to me that's worth addressing. The tradition of puzzlers is broadly educational. Does this puzzler result in a pithy Effective Scala meme? I feel it ought to. Maybe something functional like: "Be results-oriented." Because not attending to a result type is the error. I added the suggestion to add type info to express expectation or intention, to extract compiler help. I don't think the Eclipse IDE has a mode yet where it shows all the inferred types, the way it will show implicits. The other thing that always comes up on the ML is, Can I already do this with existing API. Footnote, I originally assumed that r foreach sb.append(c) looked like r foreach sb.append(c).apply, which is wrong. I could imagine adding -Xprint:typer output so that people are aware that it's normal to consult it.
@@ -60,14 +57,14 @@ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to include a "Does not compile" option as discussed, e.g.
Hello, kitteh!*
U go now.***********
- Second fails with runtime exception, first prints
Hello, kitteh!*
- First fails with runtime exception, second prints
U go now.***********
- Does not compile
Or change 1) to the "expected" answer if we want to reference that later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant to ask, it can't have 5 choices? Or does that break the computer that scores the results and notifies your preferred college and any future employer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going with your suggestion, plus expected. For future consideration, a format that asks, "Which of the following REPL sessions is correct?" This matters in that it's easier to show one line throwing, followed by another line printing. (Rather than a program terminating.) (What to show as the thrown exception is another matter.)
val sameSb: StringBuilder = sb.append('*') | ||
0 until (width - sb.length) foreach(sameSb) | ||
def pad2(width: Int) = { | ||
val sameSb: Function1[Int, Char] = sb.append('*') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps add a comment such as // append returns the StringBuilder
, or keep the StringBuilder
type declaration and add a comment that StringBuilder.apply is a Function1[Int, Char]
?
// This uses a new intermediate builder and copies before padding. | ||
// The unspecialized ++= operation is a grisly oldsb foreach { newsb += } | ||
println(new StringBuilder("U go now.") padTo (20, '*')) // the expected String, albeit built by | ||
// the unexpected StringBuilder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I think now I understand "unexpected" in this context: you mean that you actually get a new (unwanted) instance of StringBuilder here..?
Many thanks for the expanded explanation and comments! Good to go for me - any changes you'd still like to make? |
Updated #27 for more LOL, less loll.
It's worthwhile to read this after this puzzler; I tempted to write it up, if it hasn't been. |
Thanks for the pointer! I think the underlying cause - the deferred evaluation in anonymous functions - is the basis for Puzzler 22. The interesting difference here is that, of course, it's not just the arguments whose evaluation is deferred: it's the function variable itself. |
This is not a definitive version, except for the title.
There are some style differences, like one-liners, reduced use of
braces, and an implicit class to enhance StringBuilder.
In a LOL vein, padTo is renamed pad2, and it is compared to the
padTo out of the box. (It must be renamed for the extension method.)
It seems to me that's worth addressing. The tradition of puzzlers
is broadly educational.
Does this puzzler result in a pithy Effective Scala meme? I feel
it ought to. Maybe something functional like: "Be results-oriented."
Because not attending to a result type is the error. I added the
suggestion to add type info to express expectation or intention,
to extract compiler help.
I don't think the Eclipse IDE has a mode yet where it shows all the
inferred types, the way it will show implicits.
The other thing that always comes up on the ML is, Can I already do
this with existing API.
Footnote, I originally assumed that r foreach sb.append(c) looked like
r foreach sb.append(c).apply, which is wrong. I could imagine adding
-Xprint:typer output so that people are aware that it's normal to
consult it.