I am studying a material about Racket written by the great Professor Dan Grossman. He is part of the University of Washington CS Department.
At some point in his lecture notes about Racket, he describes the use
of struct and the #:transparent attribute. Despite the fact
that it clearly helps with debugging and makes a good combination with
the REPL/interactive programming, he mentions a possible damage of code modularity. To be fair, this is the quote:
First, the #:transparent attribute makes the fields and accessor functions visible even outside the module that defines the struct. From a modularity perspective this is questionable style, but it has one big advantage when using DrRacket: It allows the REPL to print struct values with their contents rather than just as an abstract value. For example, with our definition of struct foo, the result of (foo "hi" (+ 3 7) #f) prints as (foo "hi" 10 #f). Without the #:transparent attribute, it would print as #, and every value produced from a call to the foo function would print this same way. This feature becomes even more useful for examining values built from recursive uses of structs.
Ok. #:transparent makes things visible even outside the module where the struct definition was made which means that this is going to be visible in other racket files.
However, I do not get why this could be even questionable style. What could be a possible problem to illustrate this claim?
For instance, I using some structs in file1.rkt which has a (provide (all-defined-out)) to export everything. In a second file called file2.rkt, I am requiring file1.rkt and running multiple tests with rackunit. I do not see "side effects" (or something similar, like some sort of "prints"). Nothing bothers me.
Probably, Professor Grossman (who is outstanding) see things that I am not being able to see.
What am I missing? Could someone illustrate a possible problem?
