On Tue, Sep 18, 2018 at 1:04 PM <alan.f...@gmail.com> wrote:
> It would be nice, for example, to have a full range of collection types in
> the standard library without the need to use interface{}, type assertions
> and the performance overhead of 'boxing'.
>
>From the earliest days of Object Oriented Programming, the idea of abstract
data types and generic implementations of container classes has stood out
as the one (and virtually only) win for this strategy.
So let's first notice the failure: numeric types. It seems like numbers,
which fit nicely into set-theoretic classes, should be a great use of
Object Oriented structure, but as soon as you realize that the addition
operation needs to inherit from *two *separate classes a problem happens.
Smalltalk coped by having a global namespace of "priorities" for numbers,
and each numeric operation promoted the receiver or the argument as
necessary, with all kinds of really annoying manual work of just the sort
that dynamic dispatch was supposed to make unnecessary.
So Lisp had generic functions which could genuinely parameterize on the
types of more than one argument, but that still produces a disaster; to
implement addition when you have N different types requires writing
N-squared little functions. This leads to the code bloat we are familiar
with in C++ - but quadratically worse.
So numbers fail. Nobody's got a way that *actually *works. What about
containers? Also a fail. Why? Because *the implementation depends on the
use.*
A brilliant example of this was a proposed spreadsheet design. Having
noticed that X provides output windows, which can be independently moved
and updated, we'll just implement a spreadsheet by creating ten thousand
little X windows, each backed by a separate Unix process, and responsible
for displaying their value and communicating across the X server to find
the values of cells they depend on. And the server's refresh logic will
prevent unnecessary computation! Brilliant! And nothing in the
documentation of the X protocol says, "oh, by the way, that would be an
idiotic strategy".
This happens *everywhere. *We have experience that very simple types don't
require more: hash tables, arrays, pairs. But for fancy container classes?
If you want a "set" type and hash tables aren't for you, that's because
hash tables don't support operations like union and intersection. But guess
what: every implementation of union and intersection makes assumptions
about the expected use, such that misuse will result in something which is
mathematically appropriate, but a computational disaster. *There is no
generic implementation of set theoretic union and intersection which works
for all users as well as hash tables currently work for all users.*
So yes, you can implement collection classes with generics. But so what?
You don't ever want to use them. Either performance matters, and the
generic implementation will be unacceptable to anyone who isn't lucky, or
performance doesn't matter and you don't need a sophisticated collection
class at all. (Or you're in the small well-known set of data types that we
are confident *can *be implemented generically - but this is a small and
static set, and does not require general generics as part of the language.)
Thomas
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
