Re: Implementing OO

On 3 Apr 2006 01:32:55 -0400, oliverhunt@gmail.com wrote:


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


Class is a type built as a closure of a set of types. Clearly, in some
contexts the language should distinguish classes and plain types. And this
has influence on both syntax and semantics, especially for types matching.


>> - 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*)


Well, I actually didn't mean comparisons, however it is also an issue. I
rather meant declaration of new types which are either sub- or super- or
both -classes/types of other types. This is a types algebra to implement.
It is a completely new language relatively to the "non-OO" kernel. Your
point, as I understood it, could be summarized as follows. The existing
algebra providing solely aggregation (= record and array types) can be
effortlessly exploited for OO. Maybe it historically started this way, but
it is not so now.


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


Whether the parameters of a subprogram are covariant (hence dispatching) or
not. In C++ the first (hidden) parameter is covariant all others and the
result are contravariant. It is a quite strange choice, because there is
nothing special in the first parameter. Nevertheless, they are treated
differently by the compiler, especially when it comes to infix notation of
operators.


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


A subroutine can be a method (subject of inheritance) or not. Depending on
that it will be either overloadable or overridable. It can't be both
(better not.)


Both objects and subroutines can be polymorphic or not. The combination
parameter x subroutine determines whether a call will be dispatching and
whether the body will treat nested calls as dispatching.


Especially objects, when polymorphic need to keep the type tag. There is no
way to make all objects polymorphic, because that would exclude small
objects like bits, pointers and the values of type tags itself. So the
language should in some form distinguish polymorphic vs. specific objects.


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


Not necessarily. Let the code of all methods be known. Then there would be
no need to recompile it, just to set some hooks. It like declaring an array
with the number of elements determined at run-time.


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


I mean something like:


void Foo ()
{
      class FooException : public Exception {}; // Illegal in C++


      throw FooException ();
};


What is the type of the object caught outside Foo?


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

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