Re: Implementing OO

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
29 Mar 2006 18:51:46 -0500

          From comp.compilers

Related articles
Implementing OO xnooga@gmail.com (2006-03-22)
Re: Implementing OO roboticdesigner@gmail.com (MainStem) (2006-03-27)
Re: Implementing OO oliverhunt@gmail.com (oliverhunt@gmail.com) (2006-03-27)
Re: Implementing OO Ido.Yehieli@gmail.com (2006-03-27)
Re: Implementing OO mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2006-03-29)
Re: Implementing OO oliverhunt@gmail.com (oliverhunt@gmail.com) (2006-04-03)
Re: Implementing OO mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2006-04-08)
Re: Implementing OO henry@spsystems.net (2006-04-17)
Re: Implementing OO mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2006-04-21)
| List of all articles for this month |
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.compilers
Date: 29 Mar 2006 18:51:46 -0500
Organization: cbb software GmbH
References: 06-03-072 06-03-083
Keywords: OOP
Posted-Date: 29 Mar 2006 18:51:46 EST

On 27 Mar 2006 01:24:27 -0500, oliverhunt@gmail.com wrote:


> The first thing you need to realise is that classes/object orientation
> is largely syntactic sugar, a class for instance is only a struct, with
> a number of methods associated
[...]


This presumes single disipatch model. For the case of multiple dispatch
methods aren't associated with instances, they are with tuples of
instances. A more restricted case of MD is when a tuple contains only
instances from the same types hierarchy, that's a multimethod. Typical
examples are dyadic operations and assignment.


I don't agree that it is just sugar. Inheritance brings many new choices:


- class vs. type,
- supertype vs. subtype,
- convariant vs. contravariant,
- method vs. free subroutine,
- polymorhic vs. specific


etc. These choices have to be expressed syntactically, and a compiler have
to handle all that mess.


The internal infrastructure is also not an easy thing. Even in a statically
typed language which has declaration scopes, types (and so classes) could
be dynamically created and destroyed. That would require a complex
mechanics to handle dispatching tables, maybe, upward closures to prevent
instances outliving the scope of its type, etc.


--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.