Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

stackoverflow.com

Post reply on HN
Print view View original

31–40 of 80 posts

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#31

Post by sliverstorm »

mindcrime wrote: post #4

Long names are a Good Thing as far as I'm concerned. Having spent FAR more time than I care to admit working with IBM crap that uses name like QXMGRTBL and QWRKQITM, I'll take TransactionAwarePersistanceManagerFactoryProxy any day... and twice on Sunday. The only bit about this that even strikes me as a little bit unreasonable is the "Proxy" bit at the end. Not sure why you need another level of Proxy on top of Trans…

Personally, my ability to understand a line of code drops off quickly when it word wraps, and if it wraps twice I have to stop and massage my eyes.

That's the main problem with obscene verbosity in variable naming, at least to me.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#32

Post by wldlyinaccurate »

mindcrime wrote: post #20
rbehrends wrote: post #13

Earlier quoted context omitted.

The problem is not the name, but the ridiculous overdesign of which it is a symptom. At which point I bring you the story of the king's toaster [1] (which is a cautionary tale, not an aspirational story, just in case that should be unclear to anybody). ------------------------------------------------ Once upon a time, in a kingdom not far from here, a king summoned two of his advisors for a test. He showed them both…

It's an amusing story and a good cautionary tale, no doubt. But not all complex designs are over-engineering. Some problems are complex and require complex solutions. And sometimes complexity in one place is just a way of moving it from somewhere else, because somebody thought that tradeoff made their life better. See what I said below about how much I prefer JPQL and Spring Data... Personally, I really do not have a…

> Some problems are complex and require complex solutions.

And yet some very complex solutions were solved with very simple languages, before Java was conceived.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#33

Post by sukuriant »

ante_annum wrote: post #14

Remember that Sun led by example. com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter, anyone? http://javadoc.bugaco.com/com/sun/java/swing/plaf/nimbus/Int...

in an internal, unfinished, maybe even experimental (see com.sun.java.* rather than java.*) bit of code that other people in the thread are saying was auto-generated.

I don't really see that class as a problem.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#34

Post by jebblue »

nostromo wrote: post #27

I've come back to Java recently via Play Framework. To my surprise, Java can be a joy to use, so long as you avoid old-school frameworks, like Spring, entirely.

I'm starting to look more at play on the side, except for the SCala stuff I keep seeing, as long as I can use it from Java and not have to deal with Scala's weird syntax then I think Play could be the new best hope (since it's not clear what Google plans to do with GWT - which rocked).

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#35

Post by strlen »

Alternatively, this is why Java needs a real namespace mechanism. "package" doesn't cut it. See: namespaces in C# or C++, or alternately modules in ML.

One thing I like about DI implemented in a language itself is that is that it negates the need to make factories in all cases. So, essentially, imagine if Java had C# style namespace and this was done using Guice-style DI.

  bind(Persistance::Manager.class).toProvider( 
    new Provider() {    
      public Persistance::Manager get() {
        new Persistence::Manager::TransactionAware();
      }
  });

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#36

Post by jfb »

wldlyinaccurate wrote: post #32
mindcrime wrote: post #20

Earlier quoted context omitted.

It's an amusing story and a good cautionary tale, no doubt. But not all complex designs are over-engineering. Some problems are complex and require complex solutions. And sometimes complexity in one place is just a way of moving it from somewhere else, because somebody thought that tradeoff made their life better. See what I said below about how much I prefer JPQL and Spring Data... Personally, I really do not have a…

> Some problems are complex and require complex solutions. And yet some very complex solutions were solved with very simple languages, before Java was conceived.

Java is not a complicated language. Something about its affordances pushes developers into these giant labyrinthine swamps of abstraction violation, but the language isn't that complicated, either syntactically or semantically.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#39

Post by Fauntleroy »

That's not so bad. If you haven't seen the Windows 8 API documentation yet, you should go ahead and have a laugh: http://msdn.microsoft.com/en-us/library/windows/apps/br21137...

When most of your method/class names overflow your table of contents' width, you've got a serious problem.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#40

Post by cocoflunchy »

Java does not own the monopole on this one...

Ever heard of kBluetoothAMPManagerCreatePhysicalLinkResponseAMPDisconnectedPhysicalLinkRequestReceived

or

__AVAILABLE_MAC_OS_X_VERSION_10_0_AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_5

or

cairo_atsui_font_face_create_for_atsu_font_id_REPLACED_BY_cairo_quartz_font_face_create_for_atsu_font_id

?

Post reply on HN