4 ms·

The downside is that you bring in another layer of indirection and, as a result, greater cognitive load for yourself. Mycode -> facade -> library Navigating c

by jermo 11y ago

The downside is that you bring in another layer of indirection and, as a result, greater cognitive load for yourself. Mycode -> facade -> library Navigating code becomes more cumbersome and stack traces longer. I do like this approach too but it isn't free.

brianwawok 11y ago
Hah I stopped worrying about stack trace length when I started writing Scala ;) Usually only 1 or 2 lines of the trace matter, you learn to skip the rest pretty fast.
- chris_wot 11y ago
  Here's an interesting story from the Java world - "Filtering the Stack Trace From Hell": https://dzone.com/articles/spring-vs-java-ee-the-real-story-comic https://dzone.com/articles/spring-vs-java-ee-the-real-story-... An even more breathtaking stack trace image can be found here: https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstack1.png?w=630 https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstac... And the PDF version: https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstack.pdf https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstac...
mbrock 11y ago
That reminds me of another thing I'd like to tell library writers: please think of your stack traces as somewhat public, because I always end up 40 layers deep trying to debug something and it's just painful. Hopefully a facade will introduce a small constant number of stack frames... Anyway, with something like Lodash for JavaScript, I'd even want to "facade" that into a project-specific utilities thing. Right now we're on an old major version of it and upgrading would require changing hundreds of locations. When very many files in a project mention the same external dependency, that seems like a recipe for future sadness.
- kedean 11y ago
  >That reminds me of another thing I'd like to tell library writers: please think of your stack traces as somewhat public, because I always end up 40 layers deep trying to debug something and it's just painful. Unless you're using Spring, of course, then all bets are off. That's the biggest downside of IOC containers, they tend to ruin the usefulness of stack traces and the "step in/step out" functions of the debugger.
- EvanPlaice 11y ago
  A facade should only add one layer of indirection. As for project-level management of external dependencies the tooling can be used to provide a facade for imports. I'm not sure about Webpack but JSPM already does this using a config.js file that maps all of the dependencies to readable import names, sans version numbers so the site doesn't break on future updates. Ideally, once ES6 modules are used more widely it would be great to see libs start to adopt the facade pattern to provide finer granularity of control without deep linking into a project's source.
sebcat 11y ago
There was a code base where people wrapped glibc-functions. Most of the time it was straight calls to the corresponding functions in glibc, but they were called x... instead, so malloc became xmalloc, free became xfree, &c. At one time there was a lot of zombie processes lingering for a long-ish time until the parent terminated and the zombies were reaped by init. I didn't bother to look at the implementation for xpopen, as I assumed it was just a call to popen. Turned out it wasnt; it was fork/exec with a socketpair turned into a FILE* with fdopen. The child was not waited for in xpclose. I think there can be times when the facade pattern makes sense. I think there can be times when importing the world makes sense. I think there can be times when the opposite is true too. I think talking about these things in an abstract way can miss the point of the very insanity in some concrete solutions out there.
- mbrock 11y ago
  Heh. Well, yeah, abstract opinions are always suspicious. In your case, making a facade around standard POSIX functions does seem weird, especially if the facade is itself buggy! For something that needs to be portable across many platforms, such a facade could be very useful though.

by jermo 11y ago

brianwawok 11y ago

Hah I stopped worrying about stack trace length when I started writing Scala ;) Usually only 1 or 2 lines of the trace matter, you learn to skip the rest pretty fast.

chris_wot 11y ago
Here's an interesting story from the Java world - "Filtering the Stack Trace From Hell": https://dzone.com/articles/spring-vs-java-ee-the-real-story-comic https://dzone.com/articles/spring-vs-java-ee-the-real-story-... An even more breathtaking stack trace image can be found here: https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstack1.png?w=630 https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstac... And the PDF version: https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstack.pdf https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstac...

mbrock 11y ago

That reminds me of another thing I'd like to tell library writers: please think of your stack traces as somewhat public, because I always end up 40 layers deep trying to debug something and it's just painful. Hopefully a facade will introduce a small constant number of stack frames... Anyway, with something like Lodash for JavaScript, I'd even want to "facade" that into a project-specific utilities thing. Right now we're on an old major version of it and upgrading would require changing hundreds of locations. When very many files in a project mention the same external dependency, that seems like a recipe for future sadness.

kedean 11y ago
>That reminds me of another thing I'd like to tell library writers: please think of your stack traces as somewhat public, because I always end up 40 layers deep trying to debug something and it's just painful. Unless you're using Spring, of course, then all bets are off. That's the biggest downside of IOC containers, they tend to ruin the usefulness of stack traces and the "step in/step out" functions of the debugger.
EvanPlaice 11y ago
A facade should only add one layer of indirection. As for project-level management of external dependencies the tooling can be used to provide a facade for imports. I'm not sure about Webpack but JSPM already does this using a config.js file that maps all of the dependencies to readable import names, sans version numbers so the site doesn't break on future updates. Ideally, once ES6 modules are used more widely it would be great to see libs start to adopt the facade pattern to provide finer granularity of control without deep linking into a project's source.

sebcat 11y ago

There was a code base where people wrapped glibc-functions. Most of the time it was straight calls to the corresponding functions in glibc, but they were called x... instead, so malloc became xmalloc, free became xfree, &c. At one time there was a lot of zombie processes lingering for a long-ish time until the parent terminated and the zombies were reaped by init. I didn't bother to look at the implementation for xpopen, as I assumed it was just a call to popen. Turned out it wasnt; it was fork/exec with a socketpair turned into a FILE* with fdopen. The child was not waited for in xpclose. I think there can be times when the facade pattern makes sense. I think there can be times when importing the world makes sense. I think there can be times when the opposite is true too. I think talking about these things in an abstract way can miss the point of the very insanity in some concrete solutions out there.

mbrock 11y ago
Heh. Well, yeah, abstract opinions are always suspicious. In your case, making a facade around standard POSIX functions does seem weird, especially if the facade is itself buggy! For something that needs to be portable across many platforms, such a facade could be very useful though.