Re: Suggestion for strings.c

[Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>]

>  (let* ((v (gensym 'location-value))
>        (trans `(make-procedure-with-setter
>                  (lambda () ,place)
>                  (lambda (,v) (set! ,place ,v)))))

Does this mean that generalized set! is actually a procedure call?!?
I hope not.  From reading the SRFI I got the impression that:


a) it suggests that a "getter" procedure returns a location and
   set! changes this location 

b) this is not how it is implemented.  In fact (set! (getter object) val)
   is just syntactic shugar for (setter object val).


I think that both a) and b) are dangerous (and of course their
combination is even more dangerous):


a) with the message oriented style (which goops supports) an object
   protects itself from being modified.  Even if the signature specifies
   that internals can be modified, it is not a good idea to grab these
   internals, pass them around and change them later (that's what
   generalized set! suggests).  Consider the following monitor (in 
   pseudo code):

   (monitor synchronous-counter 
     (inherit ) 
     (export (count-up)
             (count-down)
             (set-counter-value)
             (set-validate-counter-value)
             (get-counter-value))

     (counter 0)

     (getter (lambda () counter))
 
     (set-counter-value
       (lambda (int)
         (set! counter 0)))

     (set-validate-counter-value
       (lambda (int)
         (and (validate int) (error "out of range"))
         (set! counter int)))

     (count-up 
       (lambda ()
         (set! counter (1+ counter))))

     (count-down 
       (lambda ()
         (if (> counter 0) 
           (set! counter (1- counter))))))


     How should a gereralized set! operate on counter?  If you
     change it from the outside (that's what set! suggests) you
     break the monitor's boundary.



b)  (set! (getter counter) -99) is re-written into
    (set-counter-value counter -99)


    As you probably know a location may either be exported
   
    1 not exported at all

    2 immutable

    3 mutable but specified modification (see set-validate-counter-value)

    4 mutable

    The problem is here that generalized set! is not general enough as
    it can only be used to change type 4 locations.  Also the syntax
    (set! (x y) val) is a bad replacement for the more descriptive setter
    "set-counter-value".


It is true that without generalized set! you must remember the
name of the setter('s) and the getter.  But note that in general
you must not only know the name of a specific setter but also the
contract you've signed by using this setter (the setter may only
accept a range of values etc.).

      
I think that #:accessor and generalized set! should be removed from
goops.


Jost
-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!