61–70 of 75 posts
Earlier quoted context omitted.
I don't think so. Interfaces dispatch based on the type of the one and only special purpose receiver.
I've read this sentence 6 times and have no idea what it means...
Earlier quoted context omitted.
+1 for mentioning BETA. Any actual user of that language?
I got to learn about it when I attended ECOOP'99. Never saw it outside the conference.
Earlier quoted context omitted.
I got to learn about it when I attended ECOOP'99. Never saw it outside the conference.
BETA was the beginner's language at the University of Dortmund (Germany) back in 1996/7/8. Never saw it outside of these buildings.
Earlier quoted context omitted.
> The trigger might have to be a little different The "dot-autocompletion" has a pretty good usability in my opinion. You write down the name of the variable, enter a dot and you get a filtered list of methods that "make sense" to call on the receiver (key word: discoverability of the API). How exactly would one implement the trigger with multimethods? I think this is an important consideration to make from a usabili…
Could swap the function name and argument list, so DoSomething(x,y,z) would become (x,y,z)DoSomething. I admit it's a little weird, but not so weird people couldn't get used to it.
Earlier quoted context omitted.
BETA was the beginner's language at the University of Dortmund (Germany) back in 1996/7/8. Never saw it outside of these buildings.
Really?! Living in Düsseldorf, small world HN. :)
I keep wondering if Go couldn't have gone further in getting rid of the cruft that has accumulated around OO. Go doesn't have an implicit "this" pointer. It doesn't have members that are private to an individual object nor members private to a type. Encapsulation exists only at the package level. Yet Go keeps that old OO concept of method receivers. Why? I never found it very plausible to have one special case parame…
Interfaces with multiple dispatch would basically be Haskell typeclasses. Typeclasses have a lot of tricky corner cases in defining their semantics, they're hard to type-inference (Haskell's type system is undecidable in some cases), and they lead to a lot of confusion for new programmers trying to learn the language. MPTCs were deliberately not standardized in Haskell 2010, because the design space around them hasn'…
Typeclasses are completely different from Go interfaces in a way that's totally unrelated to single versus multiple dispatch: in Haskell they're a bound on generic functions that specifies permissible operations, while Go interfaces are existential wrapped values. To give a concrete example of the difference here, you can write a function that takes a List of Eq values and pass a list of integers to it in Haskell, but in Go you cannot pass []int to a function that takes []Equal without recreating the list. On the other hand, in Go you can have a heterogeneous array of Equal interfaces, while in Haskell this is not possible without existential types.
> they're hard to type-inference (Haskell's type system is undecidable in some cases)
This is only when you combine the feature with type inference for functions (which Go doesn't have) and H-M style inference (which Go also doesn't have). Typeclasses would pose no problems for Go's extremely limited inference.
Pitting typeclasses against interfaces makes little sense to me; typeclasses are an enhancement to generics, while interfaces are about runtime polymorphism. Typeclasses have no meaning in a language without generics like Go (although I personally think Go will need generics eventually).
I've never seen a book with 24-point body type, except possibly for the visually impaired or 3-year-olds. Heck, most headings aren't even 24 point. What is it with this blog trend of gargantuan type, which seems increasingly common? It's totally out of proportion with the rest of anyone's OS and computer interface, and all the common sites. I'm really getting tired of having to zoom out to an insane 50% level just to make things legible again.
Off-topic, but it would be nice if the blog didn't use 24-pixel body type , so that I could see more than a handful of lines at a time on my laptop. I've never seen a book with 24-point body type, except possibly for the visually impaired or 3-year-olds. Heck, most headings aren't even 24 point. What is it with this blog trend of gargantuan type, which seems increasingly common? It's totally out of proportion with th…
P.S. the font-size is actually 1.5rem
> To apply the uniform access principle to the Part type, we could change the struct definition and provide setter/getter methods If you have to apply it, it isn't uniform access. The point of the principle is that the call-site shouldn't distinguish between getters and fields so that the implementer can change that decision freely without breaking callers. Nice article, though!