Re: Implementing OO

> 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.


Yes you're right, however i made the (potentially incorrect)
assumption that they were looking at simple single inheritance, single
dispatch. Give the nature of the question i had thought that a
reasonable assumption :)




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


Well, most of it is -- certainly the bit that most people associated
with OO, eg. instance.method()


Even virtual calls aren't too problematic (though a hell of a lot more
work)


> - class vs. type,
I actually don't know what you mean by this :)


> - supertype vs. subtype,


You're right this would be a pain for the developer to have to
implement themselves. *However* an ability to do a type comparison
(eg. Java's instanceof) is arguably a bad thing as it incourages
"switch on type" behaviour which is frowned on in some circles. (I
realise there are pros and cons to type comparisons, however my
argument is that it is not *necessary*)


> - convariant vs. contravariant,
And i've never been sure of what those words means -- feel free to
enlighten me :)


> - method vs. free subroutine,
> - polymorhic vs. specific
once again no idea what you mean :(


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


No they don't, polymorphic methods for instance can be implemented in
languages without support for OO features, and there's more overhead,
as to be understandable by people you would need to have utility
functions. Type hierarchy lookups can be performed with libraries,
once again not as efficient as a compiler doing it itself -- though
it's likely to just be dumping what would otherwise be library code
directly into the generated code.


As for the other features you talk about (namely the ones i don't know
anything about) I can't legitimately respond. Because I don't know
anything about them -- well i may, but i certainly don't recognise the
names :)


>
> 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.


Runtime type creation? Possible but not *required* for OO, in fact
I'm not sure how any non-vm/interpreted language could generate new
types at runtime, as it requires codegen -- so any compiled executable
would have to have access to the compiler.


> That would require a complex
> mechanics to handle dispatching tables, maybe, upward closures to prevent
> instances outliving the scope of its type, etc.


Dispatch tables aren't too much of a problem (unless you're generating
types at runtime) and I don't know what you mean by the remainder of
the sentence.




Apologies for the bits i didn't understand -- these are gaps in my
knowledge rather than any failure on your part to communicate :)


Cheers,
    Oliver

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