[HN Gopher] On understanding data abstraction, revisited (2009) ...
       ___________________________________________________________________
        
       On understanding data abstraction, revisited (2009) [pdf]
        
       Author : fogus
       Score  : 24 points
       Date   : 2023-06-01 17:48 UTC (1 days ago)
        
 (HTM) web link (www.cs.utexas.edu)
 (TXT) w3m dump (www.cs.utexas.edu)
        
       | discreteevent wrote:
       | Or as Gilad Bracha summarized (in reference to Cook's article):
       | "The notion of an interface is what truly characterizes objects -
       | not classes, not inheritance, not mutable state."
       | 
       | https://gbracha.blogspot.com/2022/06/the-prospect-of-executi...
       | 
       | (the "not mutable state" bit is what makes a function an object
       | for me but that's an ancient debate:
       | http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...)
        
       | cloogshicer wrote:
       | God, this is again one of those CS papers that is written as if
       | it's trying to be as inscrutable as possible.
       | 
       | Can't the author lead in by giving a simple example of both
       | abstract data types and objects (as he understands the terms), in
       | a well-known programming language?
        
         | Jtsummers wrote:
         | It's actually a pretty scrutable paper. Most of the examples
         | are in ML (or an ML-inspired notation). They are concise and
         | clear in their presentation if you spend a moment scrutinizing
         | them if you happen to be unfamiliar with the ML-family of
         | languages. It's not like he used MUMPS for his example code.
         | And his prose is reasonable, he avoids excessive notation and
         | jargon beyond what a computer scientist or programmer with
         | modest experience in a functional and an OO language ought to
         | be able to work out. It might be inscrutable to a total novice
         | or outsider, but that's probably not the target audience.
         | 
         | The core of the distinction is well-summarized with this
         | paragraph from page 7:
         | 
         | > This difference is fundamental: abstract data types have a
         | private, protected representation type that prohibits tampering
         | or extension. Objects have behavioral interfaces which allow
         | definition of new implementations at any time.
         | 
         | The other big difference is brought up on page 10 with respect
         | to the "Expression Problem". It is easier to add operations to
         | ADTs than representations, and easier to add representations
         | with objects than operations. Though this pretty clearly
         | relates back to the quote I provided. (And as he notes this has
         | been solved in various ways in various languages and systems
         | over the years; he's discussing this more from a "pure"
         | ADT/object perspective.)
        
         | jonsen wrote:
         | I don't think he can. As he says towards the end of the
         | introduction: "One source of unease is that the fundamental
         | distinctions are obscured, but not eliminated, in real
         | programming languages."
        
       ___________________________________________________________________
       (page generated 2023-06-02 23:02 UTC)