nathanleclaire / blog Goto Github PK

I found your post here: https://nathanleclaire.com/blog/2014/08/09/dont-get-bitten-by-pointer-vs-non-pointer-method-receivers-in-golang/

after reading this page: https://gobyexample.com/methods

my question is: why does go not seem to care that you pass the correct type (pointer or not) into a method?
Specifically, at the end you have a code block:

func main() {
    m := &Mutatable{0, 0} // line * below seems to work even without the & here
    fmt.Println(m)
    m.StayTheSame()
    fmt.Println(m)
    m.Mutate() . //*
    fmt.Println(m)
}

however, if you just did m := Mutatable{0, 0}, then m.Mutate() still works. Why? What is the effect of this? Why doesn't the compiler complain about m not being a pointer?

Hey Nathan,

Firstly thank you very much for you post. It was really helpful to me, since I was also kinda confused with the best practices for passing args in Go.

In line 74, you talk about pass by mechanisms in Go, which when reading it reminded me of a really interesting article about how this is handled in Go. Maybe you want to make a parenthesis referencing the article for people who are interested, if you think its reasonable. :)
It's Dave Cheney's There is no pass-by-reference in Go

Thanks once more,
Best regards,
R

it would be nice if you added a DNS resolution to the alpine-curl image you wrote by adding the --enable-threaded-resolver or --enable-ares flags. Curl can support it with --dns-servers, but I and many others online are having issues using it that your script could resolve.

There are a couple of issues with your site that are not related to the content itself.

First, I subscribed to your blog using the box on the left while I was reading an article. But then, when I reached the bottom of it, there was a modal box offering me to subscribe? not nice.

And then, I decided to read an article in bed in my phone (For the record, it's a Moto G so it has a rather nice screen resolution).

All was fine... until I got to the bottom of it. And that dreaded modal box, that in my phone (with a rather nice screen resolution, mind you) was impossible to get rid of. Now that I think about it I could had zoomed out the page; but that's not the idea, is it?

As anyone accustomed to the flexibility afforded you by langauges such as Python and Ruby may be familiar with

Also, the link at the bottom ( fix it and submit a pull request on Github) 404's on Github.

here on

NEVER EVER force push to a remote where other people are working unless:

After reading that that makes me afraid to force push, i don't know what the implication. Would you explain it to me please? @nathanleclaire

There is a technical error in the article "5 AngularJS Antipatterns & Pitfalls" . The advice regarding putting a "dot" in ng-model attribute bindings is sound, but the explanation behind it is incorrect and misunderstands the cause of the problem.

The article claims that the following directive won't work because of conflicts between a "shadow" property on the directive scope and the original property on the parent controller scope:

angular.module('dotDemo').directive('crazyAwesomeWidget', function() {
  return {
    restrict: 'E',
    template: '<input type="text" ng-model="info" />',
    scope: {
      info: '='
    }
  };
});

There's two problems with this.

1. There are no identically named properties on the OuterCtrl scope and the directive scope
2. The directive scope is isolated, owing to the inclusion of scope : { ... }, so there's never a scenario when you are looking up the prototype chain of the directive scope to find any missing properties. That only happens when you enable scope inheritance, either explicitly using scope: true or implicitly by skipping scope entirely.

The only case where people trip up on prototypal inheritance in scopes is when the following happens:

1. You have a property $scope.foo on the scope of an outer controller. It doesn't matter what data type the property holds.
2. You're using a directive with a non-isolated scope, and the directive scope inherits foo from the outer controller's scope prototypically. Retrieving $scope.foo inside the directive will result in going up the prototype chain and accessing the outer scope's foo property
3. You assign something to $scope.foo inside the directive (because of ng-model or whatever). This creates a new foo property on the directive's scope, and further references of $scope.foo no longer have anything to do with the prototype, because a foo property can be found right there on the directive scope.

This is not what is going on in the example snippet. The reason the dot is required is simply to make sure that the info property in the directive scope is never assigned to at all. You mutate the value stored in info if you store a { } and use a dot in ng-model, but you never actually update $scope.info to be something else. That's the key thing. That way, the parent scope's foo property and the isolated directive scope's foo property keep pointing at the same item.

It links to the original not to the new one