guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Guile-2.2 - goops setters should be inherited, no matter what :)


From: David Pirotte
Subject: Guile-2.2 - goops setters should be inherited, no matter what :)
Date: Sun, 26 Feb 2017 19:57:17 -0300

Hello Andy,

>  * GOOPS: are there incompatible changes that we think are bad?
>    Subthread :)  

        In my opinion, this would be the right time to make changes so that 
goops follows
        the clos protocol (for the (quite large) subset it implements), I don't
        pretend I have identified all 'breaches', but two are essential to me, 
here
        is the first (I'll post the other in another thread).

1-      setters, as in (define-method ((setter ...) (self <...>) ...) ...)
        should (also :)) be inherited,

        _whether or not_ the user defined an accessor
        
        [ see bug#19770
        [ so I can assume for this discussion we have 2 modules, (a) and (b) as
        [ defined i that bug report

Now, wrt this problem, our manual seems to follow the clos protocol, but not our
implementation. Here is what our manual says:

        ... If generic is (setter generic-with-setter), where 
generic-with-setter is
        a  variable  which is not yet bound to a generic-with-setter object, the
        expansion will include  a call to define-accessor...

So, even if I comment the accessor definition in the module (a), the expansion 
should
create one, and <b> should inherit it: in both cases an accessor is created and 
<b>
should inherit it, as well as the setter, but that is not what happens in our 
implementation.

Here is what happens if I comment the accesor defintion in (a):

        Guile 2.1.7.10-f261eaf
        scheme@(guile-user)> ,use (oop goops)
        scheme@(guile-user)> ,use (b)
        scheme@(guile-user)> (make <b>)
        $2 = #<<b> 558f91331260>
        scheme@(guile-user)> (!width $2)
        ERROR: In procedure scm-error:
        ERROR: No applicable method for #<<accessor> !width (0)> in call 
(!width #<<b> 558f91331260>)

        Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
        scheme@(guile-user) [1]> ,q

_but_ the setter has been inherited:

        scheme@(guile-user)> (set! (!width $2) 20)

        ;;; ("this is <a> !width setter method, hello!")
        $3 = 20
        scheme@(guile-user)> 

That is quite inconsistent imo. I think  we should 'clear' this up and make 
things
work as the protocol and our manual says:

        - if an accessor was not define, the seteer definition expansion should
          define one;
        
        - we should not 'force' the user to _not define_ the accessor him/her
          self, he/she should perfectly be allowed to do so (I recommend it
          actually);

        - both the accessor and the setter should be inherited

WDYT?
David

Attachment: pgpKdzdpmJVjb.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]