From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id E0B0DBD73 for ; Wed, 17 Aug 2005 00:04:31 +0200 (CEST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.194]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j7GM4Uoj014300 for ; Wed, 17 Aug 2005 00:04:31 +0200 Received: by zproxy.gmail.com with SMTP id 8so30018nzo for ; Tue, 16 Aug 2005 15:04:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=lDTcgW+5gOL3OsAjJVIkD/AF8IdARLYBFcWlnfBxpJqAx69gqFhhwrDMRRrBW+qkrCjG4hih2fIz4mkiHw/uvofUwJtB2YMoqvIlYYCfDvL7uz0WozeMh9COJbq8wHj+/O8cN0niCLHzDsUYfX6HnLAwkzpf3fHvl9mG5H1eC8w= Received: by 10.36.7.6 with SMTP id 6mr92672nzg; Tue, 16 Aug 2005 15:04:30 -0700 (PDT) Received: by 10.36.17.2 with HTTP; Tue, 16 Aug 2005 15:04:30 -0700 (PDT) Message-ID: Date: Tue, 16 Aug 2005 15:04:30 -0700 From: Nathaniel Gray To: caml-list@yquem.inria.fr Subject: Representation of objects Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Miltered: at nez-perce with ID 430262EF.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 asmrun:01 stdlib:01 invocations:01 superclass:01 bytecode:01 hash:01 cheers:01 closures:01 functions:01 essentially:01 caltech:02 caltech:02 caml:02 confused:02 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_BY_IP autolearn=disabled version=3.0.3 I've been poking around a bit into the representation of objects in OCaml and I'm a bit confused. Based on caml_get_public_method in asmrun/obj.c and various bits of stdlib/camlinternalOO.ml I see that the method table is an "array" where the even entries are closures and the odd entries "tags" -- hashed method names. (The first two entries are special.) The table is stored sorted in order of increasing tag value. Please correct me if I've misunderstood something here. I've got two questions: 1. Does this mean that essentially all method invocations need to search the method table? The method table of a superclass is no longer a prefix of that of a subclass. There's a GETMETHOD(i,obj) bytecode, but I'm struggling to figure out when you could use it. 2. What about hash collisions? There's no collision resolution code in the method lookup functions. Cheers, -n8 --=20 >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu -->