What you need is a way to override certain aspects of a transparent struct's behavior, e.g., printing. -- Matthias
On Oct 3, 2011, at 6:17 PM, Doug Williams wrote: > The main problem I see with transparent structures is that they are also > inherently mutable. Some of the operation provided may well make use of that > - for example removing whitespace. And, internally, it may be that the > structures are created and then filled - as opposed to building the > substructures and then creating the structure. I really haven't looked. > > But, in a larger sense, it is what it is. The API provides transparent > structures and there may be code that relies on it. I may even rely on it > somewhere. So, leaving then as transparent is probably the best way to go - > with prop:custom-write properties to limit the resulting print consequence. > > Rewriting it could always be Neil T's next project. :) > > Doug > > On Mon, Oct 3, 2011 at 4:06 PM, John Clements <cleme...@brinckerhoff.org> > wrote: > > On Oct 3, 2011, at 3:01 PM, Doug Williams wrote: > > > The fact that transparent structures also print all of their element - in > > this case recursively, ad nauseam - is more of a side effect. In that case, > > I think prop:custom-write properties should be added. I assume any of the > > print limiting options in my case still walk the entire structure and > > create a several tens of megabytes long string just to truncate it. > > I see. I misread your first mail as suggesting that the XML structures should > not be #:transparent. > > John > > > _________________________________________________ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev
_________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
