Re: [racket-users] structs vs classes

2017-12-07 Thread Greg Hendershott
p.s. The package supplies a `define-struct-updaters` macro separately. This is handy because you can use it on any structs -- including those from other modules you don't control. If you do this frequently for your own structs, you could of course write a little macro to `(begin (struct id ) (d

Re: [racket-users] structs vs classes

2017-12-07 Thread Greg Hendershott
On Thu, Dec 7, 2017 at 11:08 AM, David Storrs wrote: > assembled. There's no reason not to use functional update, but I > haven't seen a straightforward way to do that since there is no > 'set-db-chunk-foo' as opposed to 'set-db-chunk-foo!'. I guess I need > to use 'struct-copy'? At that point

Re: [racket-users] structs vs classes

2017-12-07 Thread Shu-Hung You
I'm not sure whether the following is a good idea, but it more or less works. The impersonate-struct function allows one to redirect the some or all of accessor and mutator functions on *individual struct instances*. If the actual constructor is hidden from the user and only a ``smart'' constructor

Re: [racket-users] structs vs classes

2017-12-07 Thread David Storrs
Wow. Thank you, Matthias. That's impressive. On Thu, Dec 7, 2017 at 10:46 AM, Matthias Felleisen wrote: > > On Dec 6, 2017, at 10:45 PM, David Storrs wrote: > > I have a struct that looks like this (simplified for concision): > > (struct db-chunk (scratchdir-path chunkdir-path) #:mutable) > >

Re: [racket-users] structs vs classes

2017-12-07 Thread David Storrs
On Wed, Dec 6, 2017 at 11:23 PM, Philip McGrath wrote: > >> 1) At least one of the fields must be set at creation > > > What does it mean for one of the fields not to be set at creation? Is there > implicitly some not-initialized value like #f that is also valid for the > constructor? Do you want

Re: [racket-users] structs vs classes

2017-12-07 Thread Matthias Felleisen
> On Dec 6, 2017, at 10:45 PM, David Storrs wrote: > > I have a struct that looks like this (simplified for concision): > > (struct db-chunk (scratchdir-path chunkdir-path) #:mutable) > > I'd like to ensure that: > > 1) At least one of the fields must be set at creation > 2) Both fields will

Re: [racket-users] structs vs classes

2017-12-06 Thread Philip McGrath
> 1) At least one of the fields must be set at creation > What does it mean for one of the fields not to be set at creation? Is there implicitly some not-initialized value like #f that is also valid for the constructor? Do you want your accessor functions to raise an error if someone tries to acce

[racket-users] structs vs classes

2017-12-06 Thread David Storrs
I have a struct that looks like this (simplified for concision): (struct db-chunk (scratchdir-path chunkdir-path) #:mutable) I'd like to ensure that: 1) At least one of the fields must be set at creation 2) Both fields will accept only a path-string? value 3) Both fields will return string? when