3 ms·

Lists are lists, and I have no issues there. It's dicts as objects (often nested) where things to get hairy. I often see folks end up relying on internal implem

by jowiar 10y ago

Lists are lists, and I have no issues there. It's dicts as objects (often nested) where things to get hairy. I often see folks end up relying on internal implementation details of other libraries, or other data sources, and things can subtly break (or explode in a ball of fire). The more systems I've built, the more I've wanted to have very well-defined seams between "inside" and "outside" -- well-defined interfaces with external APIs, libraries, databases, systems that may be maintained at a different speed, etc. Having an explicit translation/serialization/etc. step forces you to do this. It's not the only way, but pretty much every codebase I've interacted with that doesn't do this gets careless, and it's can get really messy when things get any longer than a "script".

sheepmullet 10y ago
> I often see folks end up relying on internal implementation details of other libraries, or other data sources, and things can subtly break I'm not sure how you can get around this as a consumer of a service? How do you know what is an internal implementation detail? Why are they exposing implementation details? As a producer of a service there are lots of techniques. E.g. - Only expose data and provide a spec for that data. - Provide "helper" classes in target languages for consumers to use - Publish an API spec + gaurantees - Always maintain backwards compatibility
- jowiar 10y ago
  As a consumer, you're not going to get around it. But what you can do is quarantine it to a specific area within your application. I find dependencies to be a very natural place to divide up an application -- at the very least, to consider "What would have to change if I ripped this thing out entirely?". "What are the methods I would need to implement?", etc, and writing a translation layer implementing that interface. As a hypothetical, let's say you needed to implement a binary persistence layer in your application. Rather than interacting with S3 in 10 different places, you define a "BlobStore" interface with the methods that you need, code against that interface, then implement an S3BlobStore that handles the calls to Amazon using whatever library necessary.

by jowiar 10y ago

sheepmullet 10y ago

> I often see folks end up relying on internal implementation details of other libraries, or other data sources, and things can subtly break I'm not sure how you can get around this as a consumer of a service? How do you know what is an internal implementation detail? Why are they exposing implementation details? As a producer of a service there are lots of techniques. E.g. - Only expose data and provide a spec for that data. - Provide "helper" classes in target languages for consumers to use - Publish an API spec + gaurantees - Always maintain backwards compatibility

jowiar 10y ago
As a consumer, you're not going to get around it. But what you can do is quarantine it to a specific area within your application. I find dependencies to be a very natural place to divide up an application -- at the very least, to consider "What would have to change if I ripped this thing out entirely?". "What are the methods I would need to implement?", etc, and writing a translation layer implementing that interface. As a hypothetical, let's say you needed to implement a binary persistence layer in your application. Rather than interacting with S3 in 10 different places, you define a "BlobStore" interface with the methods that you need, code against that interface, then implement an S3BlobStore that handles the calls to Amazon using whatever library necessary.