Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go and Rust – objects without class

lwn.net

Post reply on HN
Print view View original

11–20 of 60 posts

Re: Go and Rust – objects without class

#11

Post by [deleted] »

pat_punnu wrote: post #9
evincarofautumn wrote: post #5

The value of Go and Rust, I think, is that they are object-oriented languages that try to avoid conflating classes with types. If you think of a type as a set of possible values, then a subclass is actually a supertype—a superset of the possible values of its parent class—and likewise a superclass is a subtype. The “is-a” relationship is saying “for all instances I of X, I is an instance of Y” which is essentially th…

"If you think of a type as a set of possible values" You can't do that! You fall foul of Russell's paradox - sets as types simply don't work!

[deleted]

Re: Go and Rust – objects without class

#12

Post by mixedbit »

I've been recently watching Structure and Interpretation of Computer programs, where it is demonstrated that first class functions and assignment operator with nested scope are enough to implement object oriented system.

The simplest example given is a Counter object. Translated from Lisp to Javascript it goes like this:

      function make_counter() {
        var val = 0;
        function get() {
          return val;
        }
        function inc() {
          val += 1;
        }
        return [get, inc]  
      }
    
      function get_count(counter) {
        return counter[0]();
      }
    
      function inc_count(counter) {
        counter[1]();
      }
    
      var counter = make_counter();
      console.log(get_count(counter).toString());
      inc_count(counter);
      inc_count(counter);
      console.log(get_count(counter).toString());
This gives polymorphism (you can define make_fast_counter() that increases by 2 and still use get_count() and inc_count() with it) and encapsulation (you can not decrease the count).

Re: Go and Rust – objects without class

#13

Post by vanderZwan »

pat_punnu wrote: post #9
evincarofautumn wrote: post #5

The value of Go and Rust, I think, is that they are object-oriented languages that try to avoid conflating classes with types. If you think of a type as a set of possible values, then a subclass is actually a supertype—a superset of the possible values of its parent class—and likewise a superclass is a subtype. The “is-a” relationship is saying “for all instances I of X, I is an instance of Y” which is essentially th…

"If you think of a type as a set of possible values" You can't do that! You fall foul of Russell's paradox - sets as types simply don't work!

Elaborate please?

Re: Go and Rust – objects without class

#14

Post by kzrdude »

mixedbit wrote: post #12

I've been recently watching Structure and Interpretation of Computer programs, where it is demonstrated that first class functions and assignment operator with nested scope are enough to implement object oriented system. The simplest example given is a Counter object. Translated from Lisp to Javascript it goes like this: function make_counter() { var val = 0; function get() { return val; } function inc() { val += 1;…

There is a similar model in Lua by using closures for methods and upvalues for encapsulated state.

Re: Go and Rust – objects without class

#15

Post by fauigerzigerk »

riffraff wrote: post #7
evincarofautumn wrote: post #5

The value of Go and Rust, I think, is that they are object-oriented languages that try to avoid conflating classes with types. If you think of a type as a set of possible values, then a subclass is actually a supertype—a superset of the possible values of its parent class—and likewise a superclass is a subtype. The “is-a” relationship is saying “for all instances I of X, I is an instance of Y” which is essentially th…

I am not sure the issue of “I don’t make sense in this derived class” is solved by decoupling types and inheritance. For example, given the article's GO code: type file interface { Read(b Buffer) bool Write(b Buffer) bool Close() } my first thought was: wait, not all files are writable, that interface is ill specified. I do think subtyping and subclassing should be different things, but it's not a panacea against bad…

I think this points to a seperate issue as well: Often times we have a choice to express the same thing through types or through state. As the influence of functional languages grows, we tend to choose types more often.

It wouldn't be surprising to have a ReadOnlyFile type and a ReadWriteFile type. This can easily be justified because an individual file object doesn't need to change its read/write property after it has been created. But conceptually, files can be written to, just not always.

Another example makes that clearer. Adults can do things that minors can't. So, for instance, a signContract() method would have to go on the Adult type not on the Person type. But people grow older, so at any point in time some objects conceputally change their type from Minor to Adult.

Technically this is not a difficult problem to solve. But it shows the disconnect between our natural language concepts and the ever more type centered way of modelling we use in modern software design.

Re: Go and Rust – objects without class

#16

Post by Tobu »

pat_punnu wrote: post #9
evincarofautumn wrote: post #5

The value of Go and Rust, I think, is that they are object-oriented languages that try to avoid conflating classes with types. If you think of a type as a set of possible values, then a subclass is actually a supertype—a superset of the possible values of its parent class—and likewise a superclass is a subtype. The “is-a” relationship is saying “for all instances I of X, I is an instance of Y” which is essentially th…

"If you think of a type as a set of possible values" You can't do that! You fall foul of Russell's paradox - sets as types simply don't work!

Nope, Russel's paradox requires set membership axioms + a non-constructive definition of sets. Types are constructive here.

Re: Go and Rust – objects without class

#17

Post by tomp »

evincarofautumn wrote: post #5

The value of Go and Rust, I think, is that they are object-oriented languages that try to avoid conflating classes with types. If you think of a type as a set of possible values, then a subclass is actually a supertype—a superset of the possible values of its parent class—and likewise a superclass is a subtype. The “is-a” relationship is saying “for all instances I of X, I is an instance of Y” which is essentially th…

> then a subclass is actually a supertype—a superset of the possible values of its parent class—and likewise a superclass is a subtype

I'm sure this makes sense and is well-though-out, but I just can't understand it. What difference does it make if `Dog < Animal` are classes or types? Still any dog is an animal and not any animal is a dog. Or am I missing something?

Re: Go and Rust – objects without class

#18

Post by bitdiddle »

tomp wrote: post #17
evincarofautumn wrote: post #5

The value of Go and Rust, I think, is that they are object-oriented languages that try to avoid conflating classes with types. If you think of a type as a set of possible values, then a subclass is actually a supertype—a superset of the possible values of its parent class—and likewise a superclass is a subtype. The “is-a” relationship is saying “for all instances I of X, I is an instance of Y” which is essentially th…

> then a subclass is actually a supertype—a superset of the possible values of its parent class—and likewise a superclass is a subtype I'm sure this makes sense and is well-though-out, but I just can't understand it. What difference does it make if `Dog < Animal` are classes or types? Still any dog is an animal and not any animal is a dog. Or am I missing something?

you're not missing something, I believe the comment just got it flipped, and was referring[1] to problems relating to covariance and contravariance, when one tries to view OOP in terms of type theory.

[1] http://en.wikipedia.org/wiki/Covariance_and_contravariance_(...

Re: Go and Rust – objects without class

#19

Post by mseepgood »

fauigerzigerk wrote: post #15
riffraff wrote: post #7

Earlier quoted context omitted.

I am not sure the issue of “I don’t make sense in this derived class” is solved by decoupling types and inheritance. For example, given the article's GO code: type file interface { Read(b Buffer) bool Write(b Buffer) bool Close() } my first thought was: wait, not all files are writable, that interface is ill specified. I do think subtyping and subclassing should be different things, but it's not a panacea against bad…

I think this points to a seperate issue as well: Often times we have a choice to express the same thing through types or through state. As the influence of functional languages grows, we tend to choose types more often. It wouldn't be surprising to have a ReadOnlyFile type and a ReadWriteFile type. This can easily be justified because an individual file object doesn't need to change its read/write property after it h…

> As the influence of functional languages grows, we tend to choose types more often.

FP does not imply static types. See Lisp and its dialects. Don't confuse the Haskell way of doing things with FP in general.

Re: Go and Rust – objects without class

#20

Post by drothlis »

strmpnk wrote: post #3
metajack wrote: post #2

This is a good article, although I'm not sure its appropriate to post a subscriber link.

It seems like it's allowed explicitly by LWN: "The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider accepting the trial offer on the right. Thank you for visiting LWN.net!"

"Where is it appropriate to post a subscriber link? Almost anywhere. Private mail, messages to project mailing lists, and blog entries are all appropriate. As long as people do not use subscriber links as a way to defeat our attempts to gain subscribers, we are happy to see them shared."

-- https://lwn.net/op/FAQ.lwn#slinks

Post reply on HN