3 ms·

Interesting. Can this be addressed by ensuring the API of the encapsulated subsystem is sufficiently rich to provide what is needed by the declarative query pla

Interesting. Can this be addressed by ensuring the API of the encapsulated subsystem is sufficiently rich to provide what is needed by the declarative query planner? That is, the API allows the encapsulated subsystem to describe its contents in a way that supports query planning (e.g. shape of the contained data, supported operators, and general statistics), without having to reveal its exact implementation (columnar v row store, distributed v centralized storage, exact file format used, etc)? Perhaps the evolving shape of that API as the query planner becomes more capable (and therefore requires more knowledge) is what was meant by “are in tension”. Tension isn’t a bad thing. My favorite art is all about tension. Life is at its most immediate and palpable in the presence of tension.

naasking 8y ago
> Can this be addressed by ensuring the API of the encapsulated subsystem is sufficiently rich to provide what is needed by the declarative query planner? Perhaps, but this is still a clear weakening of encapsulation, and it's merely one example where it's most obvious. I think most uses of encapsulation are probably overkill anyway, necessitated only because the language is weak in other areas. For instance, encapsulation is often used to control state changes due to aliasing concerns, but if you're working with an immutable language, state change and aliasing don't conflict. Or you can go the other way, like Rust, and forbid aliasing via ownership and then state change is also easy.
skybrian 8y ago
Abstraction allows us to substitute one thing for another without breaking compatibility. This is at the heart of both API-level compatibility and also most optimizations. If two implementations weren't considered equivalent, we wouldn't be able to do the substitution without breaking things. On the other hand, if the change didn't have some important, user-visible difference (such as performance), there would be no point in doing the substitution. Now consider that most optimizations are enabled by inlining, which means that changing the internal details of a function could break optimizations in calling code and this could cause performance regression. A stricter API could prevent regressions (some bad changes are disallowed) but it also prevents good changes (they break compatibility or are disallowed optimizations). Language designers get to decide what "equivalent code" means using various forms of abstraction, but there is not going to be a perfect answer.

naasking 8y ago

> Can this be addressed by ensuring the API of the encapsulated subsystem is sufficiently rich to provide what is needed by the declarative query planner? Perhaps, but this is still a clear weakening of encapsulation, and it's merely one example where it's most obvious. I think most uses of encapsulation are probably overkill anyway, necessitated only because the language is weak in other areas. For instance, encapsulation is often used to control state changes due to aliasing concerns, but if you're working with an immutable language, state change and aliasing don't conflict. Or you can go the other way, like Rust, and forbid aliasing via ownership and then state change is also easy.

skybrian 8y ago

Abstraction allows us to substitute one thing for another without breaking compatibility. This is at the heart of both API-level compatibility and also most optimizations. If two implementations weren't considered equivalent, we wouldn't be able to do the substitution without breaking things. On the other hand, if the change didn't have some important, user-visible difference (such as performance), there would be no point in doing the substitution. Now consider that most optimizations are enabled by inlining, which means that changing the internal details of a function could break optimizations in calling code and this could cause performance regression. A stricter API could prevent regressions (some bad changes are disallowed) but it also prevents good changes (they break compatibility or are disallowed optimizations). Language designers get to decide what "equivalent code" means using various forms of abstraction, but there is not going to be a perfect answer.