If you mean you want truly decoupled views and models, you'd end up in this position:
#lang racket ;; decoupled model-view (module model racket (provide model%) (define model% (class object% (init-field view) (super-new) (define the-number 12) (define/public (setter v) (when (or (< v 0) (> 0 100)) (send view error "can't do that")) (set! the-number v)) (define/public (get) the-number)))) (module view racket/gui (provide view%) (require (submod ".." model)) (define view% (class object% (init-field model) (define frame (new frame% [width 100][height 200][label "VW"])) (define vpane (new vertical-pane% [parent frame])) (define value0 (send model get)) (define slide (new slider% [parent vpane] [label "%"] [min-value 0] [init-value value0] [max-value 100] [style '(vertical)])) (define/public (error msg) (displayln msg)) (send frame show #t)))) ;; ----------------------------------------------------------------------------- (require 'view 'model) (define the-view (new view% [model (new model% [view the-view])])) If you run this code and then call make-voew in the repl, you get an error about the use of the value the-view before its initialization. ;; ---- So here is how you do it with units: #lang racket/gui (define-signature model^ (setter get)) (define-signature view^ (error)) ;; decoupled model-view (define model@ (unit (import view^) (export model^) ;; ----------------------------------------------------------- (define the-number 12) (define (setter v) (when (or (< v 0) (> 0 100)) (error "can't do that")) (displayln `(setting to ,v)) (set! the-number v)) (define (get) the-number))) (define view@ (unit (import model^) (export view^) (define frame (new frame% [width 100][height 200][label "VW"])) (define vpane (new vertical-pane% [parent frame])) (define value0 (get)) (define slide (new slider% [parent vpane] [label "%"] [min-value 0] [init-value value0] [max-value 100] [style '(vertical)] [callback (lambda (self _e) (setter (send self get-value)))])) (define (error msg) (displayln msg)) ;; run program run (send frame show #t))) (define completly-linked-program@ (compound-unit (import) (export) (link [((model : model^)) model@ view] (((view : view^)) view@ model)))) (define (run) (invoke-unit completly-linked-program@)) ;; --- Now if you just want two modules with classes that can send message to each other, assuming that they get objects of the right kind, that's straightforward: #lang racket (module a racket (provide a%) (define a% (class object% (super-new) (define/public (mam a-b i) (displayln `(in a ,i)) (when (> i 0) (send a-b mbm this (- i 1))))))) (module b racket (provide b%) (define b% (class object% (super-new) (define/public (mbm an-a i) (displayln `(in b ,i)) (when (> i 0) (send an-a mam this (- i 1))))))) (module main racket (require (submod ".." a) (submod ".." b)) (define a (new a%)) (define b (new b%)) (send a mam b 1)) (require 'main) On May 25, 2015, at 11:58 AM, Michael Tiedtke <michael.tied...@o2online.de> wrote: > > Il giorno 25/mag/2015, alle ore 14.43, Jens Axel Søgaard ha scritto: > >> Hi Michael, >> >> It would be interesting to hear about the situation that led to a cyclic >> dependency. >> >> The few cases where I have had a problem I managed to solve it by moving >> all structure definitions into a separate module structs.rkt and then >> requiring >> that module everywhere else. >> >> /Jens Axel > > > It's in Open Flowers (on the mailing list and on planet). I wouldn't even > call it > cyclic dependency but interdependent classes. Elsewhere (I found two threads > about this subject on this mailing list) someone mentioned that the model-view > (as in model view controller) "paradigm" leads to interdependent classes. Some > call them framework which sustain themselves like a construction in euclidian > geometry ... > > Specifically the cornerstones of the table mechanic (where one can put > cards) are > interdependent. One thing that I could cut out and put into its own module in > its own > file was a simple flower dialog which works like a color chooser with a hard > coded > callback sending a message to its hosting object. Where, on the other hand, > I'm stuck > with copy&paste are the different layout classes but that might be due to my > unwillingness to abstract layouts any further. Or it had to do with the > problem of > creating a super class. Right now I can't remember ... > > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.