5 ms·

Maybe this will help people (like me, for instance) who are disgusted by the overengineered OOP-heavy approach of most Java frameworks but enjoy the concise and

by Morgawr 12y ago

Maybe this will help people (like me, for instance) who are disgusted by the overengineered OOP-heavy approach of most Java frameworks but enjoy the concise and elegant simplicity of languages like Go to finally move over and try out Android development.

bsaul 12y ago
Sure, the java bloated ecoystem is a real issue. Yet, imagine yourself building UI component without classes or inheritance ? Can't even say something like "my custom button is a special kind of android button, with just those two methods being overriden". GUI is to me the field where inheritance actually makes a lot of things easier and natural. Now you may end up with something similar using struct inheritance and manually overriding function for the given type, but i doubt most devs will go past the first unsuccesfull attempts.
- burntsushi 12y ago
  > Can't even say something like "my custom button is a special kind of android button, with just those two methods being overriden". Of course you can do that in Golang. You don't need inheritance. It has composition with type embedding. You can even "override" methods. http://play.golang.org/p/UV55gQj7t0 http://play.golang.org/p/UV55gQj7t0
  - bsaul 12y ago
    I know you can, i've explicitly talked about struct inheritance in my comment, as well as manually defining functions for the new type. Yet, this is a weird construct if all you want to do is class inheritance. You have to deal with questions like "do i want to define the func on my type, or on a pointer to that type", or "how do i call "super"", how do i extend the constructor for that new type, etc.. All those questions do have answers in golang. But you have to learn new patterns in order to do an extremely basic and common thing in OOP, once again, without much immediate apparent benefit.
    - burntsushi 12y ago
      > i've explicitly talked about struct inheritance in my comment It's not struct inheritance[1], so I wasn't sure what you were talking about. [1] - http://golang.org/ref/spec#Struct_types http://golang.org/ref/spec#Struct_types
  - scottlamb 12y ago
    > You can even "override" methods. That's not the same thing as overriding a virtual method in an OO language. If B() calls A(), it gets the general A: http://play.golang.org/p/nu7kY168E9 http://play.golang.org/p/nu7kY168E9
    - burntsushi 12y ago
      ... hence the scare quotes ...
- Morgawr 12y ago
  >imagine yourself building UI component without classes or inheritance I see no problem at all. UI development in my opinion becomes much more elegant, concise and easy to follow/reason about in a functional language that does not implement classes or inheritance. As you said, Go has struct inheritance and interfaces, that's how you do things in Go and every Go developer is familiar with the concept, it's clean and elegant. I honestly see no problem whatsoever.
  - tormeh 12y ago
    Well, if what you are doing is inheritance-heavy, then OOP features will make your code cleaner. It's what OOP is made for. You can do it in Go, but it's not as elegant.
    - NateDad 12y ago
      There is almost never code that requires inheritance.
      - jrockway 12y ago
        Inheritance, in practice, is cut-n-paste for people that think they're too smart for cut-n-paste. "Give me an object like Foo, but with this one little thing changed."
        xienze 12y ago
        Sure, you can clone Foo into Bar and change one thing in Bar. But what happens when you need to change functionality common between Foo and Bar? Oh right, you have to change the same thing in two places now. Doesn't seem so smart anymore...
        NateDad 12y ago
        This is why Go has standalone functions and interfaces. You can easily share logic between types without having the types be the same thing. The biggest problem with inheritance is that it's a lot like monkey patching (except in production)... the rest of the base class's code expects method X to do ABC, and you've just swapped out the implementation to do LMNO ... and if that never bites you in the ass, you're luckier than most OO programmers I know.
- 4ydx 12y ago
  Embedded types are king.
- spopejoy 12y ago
  GUI is to me the field where inheritance actually makes a lot of things easier and natural. I would invert that and say GUI frameworks are why bad OO/excessive inheritance is so ubiquitous. I have no idea why all the major frameworks have these horrible inheritance hierarchies, there's really no excuse for it. In my UI days, I would avoid this by having a Window or Component class extend nothing, housing the necessary component as a field. I'd extend it only if I had to (rarely, and even then usually just one or two methods), and expose it with a getter. Cleaned things up a LOT.

by Morgawr 12y ago

bsaul 12y ago

Sure, the java bloated ecoystem is a real issue. Yet, imagine yourself building UI component without classes or inheritance ? Can't even say something like "my custom button is a special kind of android button, with just those two methods being overriden". GUI is to me the field where inheritance actually makes a lot of things easier and natural. Now you may end up with something similar using struct inheritance and manually overriding function for the given type, but i doubt most devs will go past the first unsuccesfull attempts.

burntsushi 12y ago
> Can't even say something like "my custom button is a special kind of android button, with just those two methods being overriden". Of course you can do that in Golang. You don't need inheritance. It has composition with type embedding. You can even "override" methods. http://play.golang.org/p/UV55gQj7t0 http://play.golang.org/p/UV55gQj7t0
- bsaul 12y ago
  I know you can, i've explicitly talked about struct inheritance in my comment, as well as manually defining functions for the new type. Yet, this is a weird construct if all you want to do is class inheritance. You have to deal with questions like "do i want to define the func on my type, or on a pointer to that type", or "how do i call "super"", how do i extend the constructor for that new type, etc.. All those questions do have answers in golang. But you have to learn new patterns in order to do an extremely basic and common thing in OOP, once again, without much immediate apparent benefit.
  - burntsushi 12y ago
    > i've explicitly talked about struct inheritance in my comment It's not struct inheritance[1], so I wasn't sure what you were talking about. [1] - http://golang.org/ref/spec#Struct_types http://golang.org/ref/spec#Struct_types
- scottlamb 12y ago
  > You can even "override" methods. That's not the same thing as overriding a virtual method in an OO language. If B() calls A(), it gets the general A: http://play.golang.org/p/nu7kY168E9 http://play.golang.org/p/nu7kY168E9
  - burntsushi 12y ago
    ... hence the scare quotes ...
Morgawr 12y ago
>imagine yourself building UI component without classes or inheritance I see no problem at all. UI development in my opinion becomes much more elegant, concise and easy to follow/reason about in a functional language that does not implement classes or inheritance. As you said, Go has struct inheritance and interfaces, that's how you do things in Go and every Go developer is familiar with the concept, it's clean and elegant. I honestly see no problem whatsoever.
- tormeh 12y ago
  Well, if what you are doing is inheritance-heavy, then OOP features will make your code cleaner. It's what OOP is made for. You can do it in Go, but it's not as elegant.
  - NateDad 12y ago
    There is almost never code that requires inheritance.
    - jrockway 12y ago
      Inheritance, in practice, is cut-n-paste for people that think they're too smart for cut-n-paste. "Give me an object like Foo, but with this one little thing changed."
      - xienze 12y ago
        Sure, you can clone Foo into Bar and change one thing in Bar. But what happens when you need to change functionality common between Foo and Bar? Oh right, you have to change the same thing in two places now. Doesn't seem so smart anymore...
        NateDad 12y ago
        This is why Go has standalone functions and interfaces. You can easily share logic between types without having the types be the same thing. The biggest problem with inheritance is that it's a lot like monkey patching (except in production)... the rest of the base class's code expects method X to do ABC, and you've just swapped out the implementation to do LMNO ... and if that never bites you in the ass, you're luckier than most OO programmers I know.
4ydx 12y ago
Embedded types are king.
spopejoy 12y ago
GUI is to me the field where inheritance actually makes a lot of things easier and natural. I would invert that and say GUI frameworks are why bad OO/excessive inheritance is so ubiquitous. I have no idea why all the major frameworks have these horrible inheritance hierarchies, there's really no excuse for it. In my UI days, I would avoid this by having a Window or Component class extend nothing, housing the necessary component as a field. I'd extend it only if I had to (rarely, and even then usually just one or two methods), and expose it with a getter. Cleaned things up a LOT.