Live data from Hacker News

Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

stackoverflow.com

41–50 of 80 posts

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#41
post #26

I've always maintained that java itself is not so bad. It's the things people have done with it that make angels cry. People are the problem, not java. Leave java alone.

Languages aren't just syntax rules; they're ecosystems. And unless you want to build everything from scratch, you're going to need to use libraries and frameworks from that ecosystem, and you'll have to play by their rules. Further, you'll probably end up impedance-matching your code to those frameworks, just to make your architecture cleaner. Later, you'll seek help on some aspect of your project and most of the respondents' advice will follow the basic patterns of How Java is Written. Then you're going to hire additional programmers with lots of Java experience to help you build it, and they'll come with a bunch of notions on what the best practices are. So I'm not sure there's a practical distinction between "Java itself" and "things people have done with it". Java is people.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#42
knowing absolutely nothing about language design (and not many languages) other than occasional experiments in notepad... is there no language which attempts to allow spaces, maybe with quotes, for better legibility?

like instead of

    org.springframework.orm.jdo.TransactionAwarePersistenceManagerFactoryProxy
something like

    org.'spring framework'.orm.jdo.'transaction aware persistence manager factory proxy'
or is that just a terrible idea?

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#43
post #36

Earlier quoted context omitted.

> 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.

The heavy emphasis on classes is what is strange about it. Many programmers don't realize the strangeness since they've used classes their entire careers. A class isn't really a procedural concept. Nothing in a processor knows what a class is. It's more of a modeling language with an assumption that you'll architect your program to group similar methods into abstract trees of domain concepts, with your data at the leaves (instances).

So we're stuck with these complicated compile-time rules for defining everything in terms of a procedural language. We come up with complicated templates and generics for getting one set of methods to work with two types of data. Objects are needlessly serialized and deserialized to pass between systems, and programmers are needlessly spending time writing such methods.

I'm surprised that scala's paradigm of having actors work on data hasn't caught on more. When you separate them from the start, new modules are way easier to right, and integration time drops to near zero.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#44
This is obviously trolling but I'll take a stab at actually answering the question, based on the javadoc[0]. (I have never used Spring or JDO and haven't done Java server-side programming since 2002.)

The JDO framework has an interface called PersistenceManagerFactory that is used to... well, create objects that manage persistence. Spring has its own thread-bound PersistenceManager abstraction that you need to fiddle with when you're doing transactions. This class lets you use the former's interface but decorated with the latter's behavior, so code that is designed for JDO doesn't need to be modified to call the Spring APIs explicitly.

(Am I close??)

[0] http://static.springsource.org/spring/docs/2.0.7/api/org/spr...

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#46

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.

The problem here isn't their class names. It's that everyone at the empire decided to go metro a few years back and made a bunch of sites like msdn a pain to use but with a nicer font and color pallet.

My guess is no one bothered to include UX in their annual commitments when they got the memo for the design change.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#49
post #36

Earlier quoted context omitted.

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.

The heavy emphasis on classes is what is strange about it. Many programmers don't realize the strangeness since they've used classes their entire careers. A class isn't really a procedural concept. Nothing in a processor knows what a class is. It's more of a modeling language with an assumption that you'll architect your program to group similar methods into abstract trees of domain concepts, with your data at the le…

I'm not sure that's it -- ruby also has a heavy evidence on classes, but encourages entirely different sorts of solutions. Sometimes for better, occasionally for worse, but rather than argue about that, my point is just _different_ -- if emphasis on classes was what led to designs like Java, ruby would lead to em too, but it doens't, so it much be something else.

I do like the way jfb suggests using the concept of 'affordances' with languages/environments, to analyze what sorts of code they encourage. But to really do that, we'd have to actually identify these specific affordances, which i'm not sure how to either.

(And as far as your particular line of argument -- does anything in a processor know what an 'actor' is either? If not, I believe you that you find 'actor' a better abstraction than 'class', but it must not have anything to with either one being something the lower-level computer architectural abstractions 'know about')

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#50
post #42

knowing absolutely nothing about language design (and not many languages) other than occasional experiments in notepad... is there no language which attempts to allow spaces, maybe with quotes, for better legibility? like instead of org.springframework.orm.jdo.TransactionAwarePersistenceManagerFactoryProxy something like org.'spring framework'.orm.jdo.'transaction aware persistence manager factory proxy' or is that j…

I personally think that's worse. The original declaration is easier to read and immediately recognisable as to what it is, I can see clearly that it's a namespace and a class. The second version would require me to think.
Post reply on HN