undefined | Better HN

0 pointsMaulingMonkey10y ago0 comments

> #include <sin.h> #include <cos.h> #include <tan.h> #include <sinh.h>

I've written worse - at least those cover multiple variations each (or overloads in C++ for float/double/std::complex?/...)

While I'm not a fan of the enforced java route of 1 file = 1 class, I do trend towards 1 file ~ 1 (main, public) thing - which might be a single function with no overloads. #include <string_left_pad.h>? Better than #include <everything.h>, which I see far too often...

I don't have to figure out which grouping of things my coworkers decided to throw something into if I can just #include by name - whereas aggregation headers more often than not will trigger a full project file-system search.

Unnecessary #include s don't accumulate nearly so much when you don't have to audit 100 functions to see if any of them use features from said header.

I don't trigger a rebuild of everything when the only things that #include stuff actually need it.

Lots of benefits!

> and "-lsin -lcos -ltan -lsinh …"

Or sin.o, cos.o, tan.o, sinh.o... which suddenly sounds a lot more reasonable. I wouldn't bat an eye at string_left_pad.o either.

Sure, I want to use tools to simplify the use of those micro-modules by aggregating them into libraries for convenience. But that's not a knock against micro-modules - just their packaging and tooling. Rewind time back far enough and I would've been manually specifying .o files on the command line and kvetching too...

0 comments

nradov10y ago

Java doesn't enforce 1 file = 1 class but rather 1 file = 1 public class, which is exactly what you asked for. You can put as many private classes in the file as you want.

brandon7310y ago

This isn't accurate either. Java does not enforce 1 file = 1 public class but rather 1 file = 1 public top-level class.

For example this is totally legit:

  // ClassA.java
  public class ClassA {

    public static class ClassA_Inner_Public_Static {

    }

    public class ClassA_Inner_Public {

    }

  }

  // ClassB.java
  public class ClassB {

    ClassA classa = new ClassA();
    ClassA_Inner_Public classA_Inner_Public = new ClassA().new ClassA_Inner_Public();
    ClassA_Inner_Public_Static classA_Inner_Public_Static = new ClassA_Inner_Public_Static();

  }

MaulingMonkeyOP10y ago

Not exactly - I didn't ask for enforcement, and the irritation usually arises from wanting the occasional secondary type - such as an enum - to be part of the public interface (thus forcing the type itself to be public, naturally) without either:

1) moving it into a separate file, for the simplest two value one liner

2) making it interior to the other class, with all the verbose lengthy names (and semantic implications) that this might entail.

I want clear and concise names, so I lean towards #1. And if an enumeration gets more shared between multiple classes, or collects enough values and comments to merit it, sure, I'll move it into it's own file. But forcing me to shove it in a separate file before I've even decided on the best name (meaning I need to rename the file repeatedly as well), and before I'm even certain I'll keep that specific enumeration, is just meaningless friction.

j / k navigate · click thread line to collapse