Re: Is there any approach to define private vars in GOOPS?
nalaginrut nalagin...@gmail.com writes: hi all! I got a question. Is there any approach to define a private vars/methods in the GOOPS? Or it's impossible? I didn't find any private info in the GOOPS manual. Hi there! In Guile, the visibility of identifiers - including any functions you've defined to get and set GOOPS slots - is controlled by the module system, and is completely orthogonal to anything specific to GOOPS. However, the module system can't prevent any code from doing (slot-ref obj 'some-slot-that-should-be-private) once it has OBJ, and knows that OBJ has a slot named some-slot-that-should-be-private. (In effect because slot names live in a different namespace from that of identifiers, and which isn't connected to the module system.) 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
Re: Is there any approach to define private vars in GOOPS?
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 player () .. (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 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? Sorry I think the update score is a fake problem. It can be solved by #:allocation #:virtual. But I still want to talk this topic: How to hide the critical property? -- GNU Powered it GPL Protected it GOD Blessed it HFG - NalaGinrut
Re: Is there any approach to define private vars in GOOPS?
There is another approach (probably overkill) to storing private attributes of GOOPS objects, or any other Scheme object for that matter: Weak-key hash tables, documented in section 6.18.3.1 of the manual. A nice high-level interface for using them is `make-object-property'. However, it should be noted that Guile doesn't attempt to enforce strong security barriers within a single process. Even non-exported interfaces in a module can be accessed from outside using the (@@ MODULE VAR) syntax (section 6.19.2). Best, Mark Neil Jerram n...@ossau.uklinux.net writes: However, the module system can't prevent any code from doing (slot-ref obj 'some-slot-that-should-be-private) once it has OBJ, and knows that OBJ has a slot named some-slot-that-should-be-private. (In effect because slot names live in a different namespace from that of identifiers, and which isn't connected to the module system.) 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
Re: Is there any approach to define private vars in GOOPS?
On Wed 09 Mar 2011 10:37, nalaginrut nalagin...@gmail.com writes: But I still want to talk this topic: How to hide the critical property? I don't know what the GOOPS / CLOS answer is to this, but more generally, you might enjoy the following paper: http://mumble.net/~jar/pubs/secureos/ Regards, Andy -- http://wingolog.org/
