> With fallback methods, you can get the best of both worlds. > > You can have a base set of methods that implementers of the interface > need to write, and from which everything else can be derived. The > derived methods can also be present in the interface, which allows > implementers to override them if, e.g., their particular data structure > can implement them more efficiently. > > For example, let's say you're implementing a vector-like data > structure. You can implement, say, `map` efficiently by allocating a > vector of the right size at the start, then filling it up. By overriding > the `map` method, this more efficient version will be used instead of > the fallback. > > The `set` library uses this pattern.
Yes, I agree, and I think another thing that will need to come along with this is a better set of documentation forms for generic interfaces. Currently, documenting generic interfaces is fairly ad- hoc, and expressing which methods are required and which are optional is unclear. > FWIW, that's pretty close to what Racket's `sequence` datatype (not the > interface) does. I haven't seen much code that uses them directly. I think this is mostly because the only way to create sequences is make-do-sequence, which is honestly terrible. As far as I can tell, it is neither more efficient nor more expressive than gen:stream, but the latter is far simpler and more natural to write. I don't really see the need for sequences in the racket/base sense, but streams are a good foundation for most lazy sequences, which is what I've employed for most of the lazy functionality I've used so far. -- 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.
