51–60 of 153 posts
Earlier quoted context omitted.
Less than 5% of your coworkers understand decorators? I don't want to sound snooty but this is a pretty trivial application of higher order functions.
I have to agree; it's basic stuff even for a Python weenie like me.
Interesting that this snippet: func (g *Gopher) DumpBinary(w io.Writer) error { err := binary.Write(w, binary.LittleEndian, int32(len(g.Name))) if err != nil { return err } _, err = w.Write([]byte(g.Name)) if err != nil { return err } err = binary.Write(w, binary.LittleEndian, g.Age) if err != nil { return err } return binary.Write(w, binary.LittleEndian, g.FurColor) } could be written like this: func (g *Gopher) Dum…
http://golang.org/src/pkg/text/template/helper.go?s=576:619#...
Earlier quoted context omitted.
> Didn't read, because mouse scroll wheel doesn't work. You don't need the scroll wheel to navigate the presentation. Click on the right side of the slide to go forward, on the left side to go back. > Honestly, who thinks this stuff is a good idea? People who are making presentations to deliver in an in-person setting where putting them on the web for everyone is a secondary use, not the primary use? I mean, looking…
Also, you can use the arrow keys to go back and forth through the slides.
Odd choice of examples... 1. The file I/O makes the case for including exceptions in the language. Specifically, adding one-off types to deal with exceptions is a bug, not a feature. There is a good case against exceptions but that ain't it. 2. On slide 5, it appears to show that you have to use a switch statement on a generic to get polymorphism because the language doesn't support overloading. Again, looks more lik…
Exceptions are included in the language, they are called panics, and the go convention is that libraries don't expose them in the public interface, but can use them internally (and, of course, application code can use them.)
> Specifically, adding one-off types to deal with exceptions is a bug, not a feature.
One-off types aren't used for error handling in the example, they are used for abstracting a writing pattern that works like binary.Write for writing non-string values and like io.Writer#write for string values. Sure, the special type's write method also swallows errors, but, except that the mechanism by which it swallows errors would look different, the use of the one-off type and its write method would be pretty much the same with exceptions/panics as with error returns from the underlying library functions.
Earlier quoted context omitted.
I have to agree; it's basic stuff even for a Python weenie like me.
It's basic stuff because you're a Python weenie; I don't see much use or discussion of decorators outside the Python world.
Earlier quoted context omitted.
I have to agree; it's basic stuff even for a Python weenie like me.
It's basic stuff because you're a Python weenie; I don't see much use or discussion of decorators outside the Python world.
Which are pretty important, and not specific to python.
Earlier quoted context omitted.
I have to agree; it's basic stuff even for a Python weenie like me.
It's basic stuff because you're a Python weenie; I don't see much use or discussion of decorators outside the Python world.
def with_error_handler
if error = yield
puts "error: #{error}"
end
end
def do_things
error = do_this
return "error doing this: #{error}" if error
error = do_that
return "error doing that: #{error}" if error
nil
end
with_error_handler do
do_things
end
Earlier quoted context omitted.
Even the correct version is not that good. The multiple checks on nil is an obvious pattern and as such should be abstracted away. Haskell does it with Maybe but as long as you have function as first class object, it should be doable. Like in Python, Ruby, etc.
The very next slide cleans it up using a "utility type" which reminds me of the "monadic" Haskell solution.
If #6 is among best practices, I'm sad. I could take a dynamically-typed language instead. http://talks.golang.org/2013/bestpractices.slide#6
They allow dynamically typed methods when you need them. Why does that make you sad?
Well, Go 1 has some of the problems of Java 1: no generics, typecasts from interface{} here and there, simplistic GC. Reasons are probably similar: this all is good enough for version 1, and can later be improved upon.
Odd choice of examples... 1. The file I/O makes the case for including exceptions in the language. Specifically, adding one-off types to deal with exceptions is a bug, not a feature. There is a good case against exceptions but that ain't it. 2. On slide 5, it appears to show that you have to use a switch statement on a generic to get polymorphism because the language doesn't support overloading. Again, looks more lik…
> The file I/O makes the case for including exceptions in the language. Exceptions are included in the language, they are called panics, and the go convention is that libraries don't expose them in the public interface, but can use them internally (and, of course, application code can use them.) > Specifically, adding one-off types to deal with exceptions is a bug, not a feature. One-off types aren't used for error h…
In his example, he uses a one-off type to isolate the caller from having to explicitly check if each individual write failed. I got no problem with that.
But it seems like it a work-a-round.
It's just an odd choice for an example. The take-a-way seems to be that the basic class libraries need a wrapper that makes them easier to work with and that, you the developer, should build these wrappers so you know exactly what the policy is.