From: james woodyatt <jhw@wetware.com>
To: Alessandro Baretta <alex@baretta.com>
Cc: Ocaml <caml-list@inria.fr>
Subject: Re: [Caml-list] Allow declaring classes "final" so self type has no type variables?
Date: Fri, 6 Sep 2002 14:15:39 -0700 [thread overview]
Message-ID: <CB78D5D0-C1DD-11D6-8D7B-000393BA7EBA@wetware.com> (raw)
In-Reply-To: <3D79125F.1090005@baretta.com>
On Friday, Sep 6, 2002, at 13:38 US/Pacific, Alessandro Baretta wrote:
> james woodyatt wrote:
>> On Friday, Sep 6, 2002, at 12:12 US/Pacific, Tim Freeman wrote:
>>>
>>> Any comments on whether this is a good idea?
>>
>> Hide the class with a module signature. Publish only the class type
>> and one or more functions for constructing objects.
>
> I don't think this is what he meant. I think he would like to
> "finalize" a class for efficiency purposes as opposed to "safety"
> purposes. He is asking for some compiler magic.
The opportunity to optimize method dispatch simply isn't there. The
reason is that two objects with identical class types need not have
methods with the same definition.
> # class a = object method f = print_string "a\n" end;;
> class a : object method f : unit end
> # class b = object method f = print_string "b\n" end;;
> class b : object method f : unit end
> # let print (p : a) = p#f;;
> val print : a -> unit = <fun>
> # print (new b);;
> b
> - : unit = ()
In the above excerpt, class a and class b are different classes with
equivalent class types. The function 'print' may look like it requires
objects constructed of class a, but all it really requires is objects
of class type a (and since class type b is equivalent to class type a,
objects of class b will work just as well).
And anyway... last I checked, method dispatch was not the low-hanging
fruit for optimizing Ocaml code with objects and classes. The size of
class initializers (generated by the compiler and executed in enclosing
module initializers) are where it seems to me the big opportunities are
to be had.
--
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
next prev parent reply other threads:[~2002-09-06 21:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-06 19:12 Tim Freeman
2002-09-06 20:18 ` james woodyatt
2002-09-06 20:38 ` Alessandro Baretta
2002-09-06 21:15 ` james woodyatt [this message]
2002-09-11 0:16 ` Tim Freeman
2002-09-11 5:09 ` james woodyatt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CB78D5D0-C1DD-11D6-8D7B-000393BA7EBA@wetware.com \
--to=jhw@wetware.com \
--cc=alex@baretta.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox