2 ms·

> The OO stuff is basically like an old version of Java and a bit tedious to write. An IDE is definitely required The OO 'stuff' in PHP is far better. Notably,

> The OO stuff is basically like an old version of Java and a bit tedious to write. An IDE is definitely required The OO 'stuff' in PHP is far better. Notably, Traits, Statics and Testing. Java (and JUnit) do not work well with static methods/classes, when it's unironically the most effective way to limit state. In PHP you can create a static class, that has static utility methods. Now you can ensure you have no side effects - unless accessing static properties somewhere, ofc. Then PHPUnit has no trouble helping you test these. It's a huge improvement over the acrobatics of booting up Spring to manage a singleton (which isn't the same thing as a static class) whenever you want access to those real static methods.

emodendroket 5y ago
I'm not sure what about Java is stopping you from making static classes.
- Supermancho 5y ago
  > I'm not sure what about Java is stopping you from making static classes. I didn't imply that you couldn't make a static class in Java. There are lots of ways to make something like a top level static class (nested static, Spring singletons, et al), which works against the explicitly stated purpose of limiting state involvement.
  - emodendroket 5y ago
    Those limitations are a little annoying but I'm not sure how they're preventing you from doing what you want to do, and having top-level statics wouldn't limit someone from just sneaking global state in there either.
    - deleted 5y ago
      [deleted]
    - Supermancho 5y ago
      @Test public void testSomeMethod_FromStatic() { StaticWrapper1 staticWrapper = new StaticWrapper1(); int mockInput = 1; RegularClass rc = new RegularClass(); int expected = 2; int ret = staticWrapper.someStaticClass.someMethod(rc, mockInput); verify(staticWrapper.someStaticClass, times(1)).someMethod(rc, mockInput); assertEquals(expected, ret); } public class StaticWrapper1 { static class StaticClass { public int someMethod(RegularClass foo, int val){ return foo.someAddMethod(val); /* it's not practical to chain, eg staticWrapper2.someAddMethod(foo, val); because you end up with circular dependencies or passing large numbers of deps around, which you can't verify in tests anyway */ } } } You cant do this (verify the static call) by default nor anything more complicated than this (with Mockito Static mocking) because JUnit cant track deps through statics for testing. If you have multiple static objects that have static methods, you end up with brittle chains of instances that might need to refer to (either passed in or member instances of wrappers) just to call other static methods. This is inferior to PHPUnit. Making syntactical boilerplate "just because", which also requires instantiation breaking DI (ostensibly, all you have to do is boot up Spring IoC container and it's there are runtime), is inferior to PHP. Maybe one day Spring will be baked into Java, but that's a one-ton runtime workaround for a small mistake in the core philosophy, ie you can put a non-static function around a static function and treat it as the static, so it's a JVM problem. Pushing explicit instancing to the code is bad design from a makeshift solution to get Java working on older platforms, quickly. Now java does prechecking of memory anyway, so the way you have to do static implementation is an extraneous legacy limitation.
      - emodendroket 5y ago
        Right, I mean, if you need to mock it a singleton would be a better choice; that's kind of the point of the pattern. Personally, though, I feel like if you frequently find yourself needing to mock these static classes, then they're not really as effective at avoiding statefulness as you claim -- if they're side effect-free, it should be safe to just use the implementation.
        5y ago

emodendroket 5y ago

I'm not sure what about Java is stopping you from making static classes.

Supermancho 5y ago
> I'm not sure what about Java is stopping you from making static classes. I didn't imply that you couldn't make a static class in Java. There are lots of ways to make something like a top level static class (nested static, Spring singletons, et al), which works against the explicitly stated purpose of limiting state involvement.
- emodendroket 5y ago
  Those limitations are a little annoying but I'm not sure how they're preventing you from doing what you want to do, and having top-level statics wouldn't limit someone from just sneaking global state in there either.
  - deleted 5y ago
    [deleted]
  - Supermancho 5y ago
    @Test public void testSomeMethod_FromStatic() { StaticWrapper1 staticWrapper = new StaticWrapper1(); int mockInput = 1; RegularClass rc = new RegularClass(); int expected = 2; int ret = staticWrapper.someStaticClass.someMethod(rc, mockInput); verify(staticWrapper.someStaticClass, times(1)).someMethod(rc, mockInput); assertEquals(expected, ret); } public class StaticWrapper1 { static class StaticClass { public int someMethod(RegularClass foo, int val){ return foo.someAddMethod(val); /* it's not practical to chain, eg staticWrapper2.someAddMethod(foo, val); because you end up with circular dependencies or passing large numbers of deps around, which you can't verify in tests anyway */ } } } You cant do this (verify the static call) by default nor anything more complicated than this (with Mockito Static mocking) because JUnit cant track deps through statics for testing. If you have multiple static objects that have static methods, you end up with brittle chains of instances that might need to refer to (either passed in or member instances of wrappers) just to call other static methods. This is inferior to PHPUnit. Making syntactical boilerplate "just because", which also requires instantiation breaking DI (ostensibly, all you have to do is boot up Spring IoC container and it's there are runtime), is inferior to PHP. Maybe one day Spring will be baked into Java, but that's a one-ton runtime workaround for a small mistake in the core philosophy, ie you can put a non-static function around a static function and treat it as the static, so it's a JVM problem. Pushing explicit instancing to the code is bad design from a makeshift solution to get Java working on older platforms, quickly. Now java does prechecking of memory anyway, so the way you have to do static implementation is an extraneous legacy limitation.
    - emodendroket 5y ago
      Right, I mean, if you need to mock it a singleton would be a better choice; that's kind of the point of the pattern. Personally, though, I feel like if you frequently find yourself needing to mock these static classes, then they're not really as effective at avoiding statefulness as you claim -- if they're side effect-free, it should be safe to just use the implementation.
      - 5y ago