On May 26, 2015, at 1:10 AM, Michael Tiedtke wrote:
Sorry, ut I call it a workaround.
Please read up on programming language design.
--
You received this message because you are subscribed to the Google Groups
Racket Users group.
To unsubscribe from this group and stop receiving emails
Il giorno 26/mag/2015, alle ore 17.11, Matthias Felleisen ha scritto:
On May 26, 2015, at 11:00 AM, Michael Tiedtke michael.tied...@o2online.de
wrote:
Il giorno 26/mag/2015, alle ore 14.17, Matthias Felleisen ha scritto:
On May 26, 2015, at 1:10 AM, Michael Tiedtke wrote:
As I had to find out Racket's module system doesn't support cyclic
dependencies. In that case I should use units. But as far as I have understood
the concept of full fledged units I must either write a lot of redundant code
like signature auto^, implementation auto@, import auto^, require
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
On May 25, 2015, at 5:52 AM, Michael Tiedtke wrote:
As I had to find out Racket's module system doesn't support cyclic
dependencies. In that case I should use units. But as far as I have
understood the concept of full fledged units I must either write a lot of
redundant code like
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
Il giorno 25/mag/2015, alle ore 14.29, Matthias Felleisen ha scritto:
On May 25, 2015, at 5:52 AM, Michael Tiedtke wrote:
As I had to find out Racket's module system doesn't support cyclic
dependencies. In that case I should use units. But as far as I have
understood the concept of
On May 25, 2015, at 3:19 PM, Michael Tiedtke michael.tied...@o2online.de
wrote:
See, you're doing away with the class definitions and substitute them with
unit definitions.
This is what I meant when I wrote you recreated encapsulation and
inheritance. (Because
linking somehow resembles
Il giorno 25/mag/2015, alle ore 19.31, Matthias Felleisen ha scritto:
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%
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)
Would lazy-require work here?
http://docs.racket-lang.org/reference/lazy-require.html
On Mon, May 25, 2015 at 3:56 PM, Matthias Felleisen matth...@ccs.neu.edu
wrote:
On May 25, 2015, at 3:19 PM, Michael Tiedtke michael.tied...@o2online.de
wrote:
See, you're doing away with the class
No.
On May 25, 2015, at 6:59 PM, Luke Whittlesey wrote:
Would lazy-require work here?
http://docs.racket-lang.org/reference/lazy-require.html
On Mon, May 25, 2015 at 3:56 PM, Matthias Felleisen matth...@ccs.neu.edu
wrote:
On May 25, 2015, at 3:19 PM, Michael Tiedtke
Il giorno 25/mag/2015, alle ore 21.56, Matthias Felleisen ha scritto:
...
Yes, I was thinking about things like these in my other message. But
this alreaddy depends on the evaluation order which can be reversed.
Right in this example one would like to mix in lazy evaluation.
(define
13 matches
Mail list logo
