3 ms·
I always wondered why there weren't more 'hyper-collection' abstractions that just implement multiple collection types in one interface, so that you can get the
by arthurcolle 5y ago
I always wondered why there weren't more 'hyper-collection' abstractions that just implement multiple collection types in one interface, so that you can get the respective speedups of the different collection types while still having the flexibility to use them as you wish
- ketralnis 5y agoC arrays are basically that. Also python dicts (most python types including all user-defined classes are actually dicts underneath), Lua tables, Javascript objects, and more. In most dynamically typed languages, "the" type is actually what you're calling a hyper-collection and not just conceptually, but also in implementation
- karmakaze 5y agoThis is the field of datastructures. There isn't 'just' one be-all to end-all. There are so many kinds of hashing/tables, trees/balancing, hybrid (e.g. skiplists), priority queues, etc. Because there are so many possible combinations, if the choices matter it's useful to use a language that lets you make your own. This is one of the main reasons why generics for Go is a big deal. Go always had generics, but it's only been for the built-ins array/slice, map, and channel. With user-defined generics any datastructures/interfaces can be conveniently made and used without language/library/compiler support. Its curious that for Python this is blog post material, but for Go it's intrinsic to understanding the performance and usage of slices or maps, or in Java (and other langs) would be referenced merely by the class name ArrayList. The fact that so much can be done effectively in Python without always having to think about such details is an achievement of the language and ecosystem of libraries and packages.
- beervirus 5y agoHow would that work? Every time you create an object, internally it creates one of everything?