Avoid Else, Return Early (2013)

Re:Avoid Else, Return Early (2013) by brianpan on Monday March 26, 2018 @04:42PM (#16682392)

I think this might partially be related to the move towards streaming applications and microservices. You could create objects for everything you expect to receive/send and then when an API changes you lose the new fields, you get parse errors, etc. If you did it right maybe you can avoid some of those things, but the bottom line is that type safety is a little bit too strong a constraint for these use cases.

Even if I'm getting from a DB which won't be changing out from under me, many times I'd prefer just getting a simple Map rather than spending time creating a "safe" object. Do I create a User and UserWithDetails? Or always return UserWithDetails but sometimes fields are empty because I don't care about them? Dicts are light, objects are cumbersome.

[ Parent | on HN ]

Re:Avoid Else, Return Early (2013) by boomlinde on Tuesday March 27, 2018 @09:53AM (#16688332)

You can of course create a User and a UserDetails, the former embedding the latter when necessary.

I also see getting parse errors when APIs change as a positive thing. When you change an API, things do break. Learning what breaks as early as possible is good. It's not even about objects vs. dictionaries, you could use any structured composite datatype and the overhead you associate with it depends very much on the language.

Of course, for a quick hack I'd happily dump data into a dictionary and call it a day. But if I want to learn why it breaks 5 years later, having a clear specification of the expected data is much better even if it cost me an extra few hours.

[ Parent | on HN ]