Is there any approach to define "private" vars in GOOPS?

Is there any approach to define "private" vars in GOOPS?

[nalaginrut]

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.


-- 
GNU Powered it
GPL Protected it
GOD Blessed it

HFG - NalaGinrut

Re: Is there any approach to define "private" vars in GOOPS?

[Neil Jerram]

nalaginrut <nalaginrut@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?

[nalaginrut]

> 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?

-- 
GNU Powered it
GPL Protected it
GOD Blessed it

HFG - NalaGinrut

Re: Is there any approach to define "private" vars in GOOPS?

[nalaginrut]

> > 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?

[Andy Wingo]

On Wed 09 Mar 2011 10:37, nalaginrut <nalaginrut@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/

Re: Is there any approach to define "private" vars in GOOPS?

[Neil Jerram]

nalaginrut <nalaginrut@gmail.com> writes:

> 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?" 

With apologies for the late reply...

I guess something like this (untested):

(define valid-score-update #f)
(define slot-setter-if-valid-scope #f)

(let ((valid-scope #f))
  (set! valid-score-update
        (lambda (player newscore)
          (set! valid-scope #t)
          (slot-set! player 'score newscore)
          (set! valid-scope #f)))
  (set! slot-setter-if-valid-scope
        (lambda (obj new-val)
          (or valid-scope
              (error "Not in valid scope!"))
          (set! (score obj) new-val))))

Then use `valid-score-update' in the definition of the score-update
method, and `slot-setter-if-valid-scope' as the #:slot-set! option of
your virtual 'score slot.

I've assumed that (score obj) provides the real underlying storage for
the virtual slot; it could be a (make-object-property), for example.

Unfortunately I'd say this adds up to an over-contrived solution; but
hopefully it's still useful to show how it _could_ be done.

Regards,
        Neil

Re: Is there any approach to define "private" vars in GOOPS?

[Mark H Weaver]

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 <neil@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