From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.0 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 9C823BC6B for ; Mon, 10 Dec 2007 15:00:44 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAPLUXEfRVca/i2dsb2JhbACPZAEBAQgEBCQFgRY X-IronPort-AV: E=Sophos;i="4.23,276,1194217200"; d="scan'208";a="6663035" Received: from discorde.inria.fr ([192.93.2.38]) by mail3-smtp-sop.national.inria.fr with ESMTP; 10 Dec 2007 15:00:44 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id lBAE0ftr001663 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 10 Dec 2007 15:00:44 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAPLUXEfRVca/i2dsb2JhbACPZAEBAQgEBCQFgRY X-IronPort-AV: E=Sophos;i="4.23,276,1194217200"; d="scan'208";a="6663032" Received: from rv-out-0910.google.com ([209.85.198.191]) by mail3-smtp-sop.national.inria.fr with ESMTP; 10 Dec 2007 15:00:43 +0100 Received: by rv-out-0910.google.com with SMTP id f5so1487826rvb for ; Mon, 10 Dec 2007 06:00:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=DxRMxX61zeEDF6FREp7qfGuxmex4zEUGCwGtIzQ1D9M=; b=A7LkbvxMKDnAhsAOUS2/iAh1KJCfQGS2Bw8q4cFEuGE585+oNkzcdRF6Zbp2l9VRd1TgKniPzG7Pw5DRkE/BhHiN5wKAH69/90PaL7JzZZxwFYkyWQBYtsPkCNszs6tqDUxoSTSTicx0nWvPa5cufLcLQ5BInXBwJf0nYbxElr8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VajuwtAjNYqZJi78df15isYXniiTYOpd/DT60ofxSp2VjXg5yTNT7CGk1D3Fj/QxpDDR/PxdCLsP3kVxh1RSRHAZ4K6xmrcUjAG6ceCW77IZz/jc54VGVAfkLfS6VlzNvNzUyqsBhb4+JGQIucSFSkQXT8Vvbv7ql3qsCPIwi5I= Received: by 10.141.167.5 with SMTP id u5mr4246703rvo.1197295241782; Mon, 10 Dec 2007 06:00:41 -0800 (PST) Received: by 10.140.200.16 with HTTP; Mon, 10 Dec 2007 06:00:41 -0800 (PST) Message-ID: <90823c940712100600h5d748658x5e4647169500a917@mail.gmail.com> Date: Mon, 10 Dec 2007 17:00:41 +0300 From: "Dmitry Bely" To: "Jacques Garrigue" Subject: Re: [Caml-list] Class runtime representation Cc: caml-list@inria.fr In-Reply-To: <20071208.223648.27836833.garrigue@math.nagoya-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <90823c940712070559i5c435a10l76bbb3ec328690aa@mail.gmail.com> <20071208.223648.27836833.garrigue@math.nagoya-u.ac.jp> X-Miltered: at discorde with ID 475D4689.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; runtime:01 ocaml:01 hash:01 statically:01 runtime:01 functors:01 wrote:01 naming:01 dmitry:01 dmitry:01 caml-list:01 conflicts:01 conflicts:01 bely:01 bely:01 On Dec 8, 2007 4:36 PM, Jacques Garrigue wrote: > Names are only used during class construction, which is dynamic in > ocaml. Names are used for methods (both public and private) and > instance variables. Of all those, only public methods use a hashed > values in other operations, and for this reason public methods in the > same class are guaranteed to have no hash conflicts. But this is not > enforced for private methods, which can always be called in a more > direct way. And since some internal data structures mix private and > public methods, it seems simpler to have names for all. > > Now, as we can also statically detect potential conflicts between > private methods, it would be possible to use hashed tags for private > methods too (and even instance variables). This might improve code > size, as names would disappear from the runtime. This would not change > performance however, as class construction only occurs once for most > class declarations, and a fixed number of times in more complex > examples combining inheritance and functors. And it would introduce a > new restriction on the naming of private methods. Thanks for the detailed explanation. I don't like method names in the binary because they show some implementation details that I would like to hide; several extra bytes of code are really not a problem. - Dmitry Bely