From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: nalaginrut Newsgroups: gmane.lisp.guile.user Subject: Re: Is there any approach to define "private" vars in GOOPS? Date: Wed, 09 Mar 2011 17:27:25 +0800 Organization: HFG Message-ID: <1299662845.2577.82.camel@Renee-desktop> References: <1299638259.2577.5.camel@Renee-desktop> <87d3m0llza.fsf@ossau.uklinux.net> Reply-To: NalaGinrut@gmail.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1299662895 2153 80.91.229.12 (9 Mar 2011 09:28:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 9 Mar 2011 09:28:15 +0000 (UTC) Cc: Guile To: Neil Jerram Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Mar 09 10:28:11 2011 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PxFgg-0004yM-T6 for guile-user@m.gmane.org; Wed, 09 Mar 2011 10:28:11 +0100 Original-Received: from localhost ([127.0.0.1]:36523 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PxFgf-0000ye-Sd for guile-user@m.gmane.org; Wed, 09 Mar 2011 04:28:09 -0500 Original-Received: from [140.186.70.92] (port=34825 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PxFg7-0000vt-PO for guile-user@gnu.org; Wed, 09 Mar 2011 04:27:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PxFg6-0002FO-LE for guile-user@gnu.org; Wed, 09 Mar 2011 04:27:35 -0500 Original-Received: from mail-yx0-f169.google.com ([209.85.213.169]:38323) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PxFg6-0002FF-I0 for guile-user@gnu.org; Wed, 09 Mar 2011 04:27:34 -0500 Original-Received: by yxt33 with SMTP id 33so215509yxt.0 for ; Wed, 09 Mar 2011 01:27:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:from:reply-to:to:cc:in-reply-to :references:content-type:organization:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=p7HlKemwvg7QgGUOPhqmW3Il6gHqcv9oHphK7BNf2dk=; b=dkstQBqEbUGBbjKe03qOEWm6ErYrjwE+0OlHux+5R1LUOlsyXNqGEHMf7XmVh1r5AY OWzowcVmQtaC6/cQd2u7z2uq5Se7ePt7/7mptGfus/nc33Nl/ZYM5v352ef19aXE9RMK GWYRCR0t6insdYDbt9CGKvBB5Y1eDo3Fd1ZqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:reply-to:to:cc:in-reply-to:references:content-type :organization:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=A6L9h2mVtJbQAF0mpE3ptFTosbkTcDBB5o7z1FD//MPS8ouKpUedAVA2CEpMSiaK9h SYOpC8b/Cwx/w8NdkPQX9yJLU/Sa+rAVILY3flceYl1mVHHELVtdfZXvTp9L/EGuwkDb 30MNgt7QGVzPfOm7pA7o6a6FnhWmqsTinjk/0= Original-Received: by 10.150.147.12 with SMTP id u12mr7232227ybd.404.1299662853923; Wed, 09 Mar 2011 01:27:33 -0800 (PST) Original-Received: from [192.168.100.100] ([183.15.176.36]) by mx.google.com with ESMTPS id l2sm1337560ybn.15.2011.03.09.01.27.28 (version=SSLv3 cipher=OTHER); Wed, 09 Mar 2011 01:27:33 -0800 (PST) In-Reply-To: <87d3m0llza.fsf@ossau.uklinux.net> X-Mailer: Evolution 2.28.3 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.213.169 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:8503 Archived-At: > If you can determine at runtime whether or not any given slot access is > allowed - perhaps based on (current-module) - it should be possible to > enforce this by defining a new kind of slot #:allocation and putting > that runtime check in the #:slot-ref function. > > Regards, > Neil Thanks for your answer :-) But I think a new kind of slot allocation seems not easy. For example. If I got a class "player", and assume we've already defined a new kind allocation, say, #:allocation #:private. =============================== (define-class () ...... (score #:init-value 0 #:allocation #:private) ......) ===== I don't want somebody change "score" except calling a method to compute his real score. And I have a method to update player's score: ===== (define-method (score-update (player )) ... (slot-set! (slot-ref player 'score) newscore) ... ) ======================== The problem is how to check the scope of "score" from "score-update". I've no idea because the definition of "score-update" is actually out of the class definition. Can I get some advice about the topic "how to hide the critical property"? Or maybe I have some misunderstandings? -- GNU Powered it GPL Protected it GOD Blessed it HFG - NalaGinrut