[jboss-dev-forums] [JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor

[david.lloyd@jboss.com]

"alesj" wrote : "david.lloyd at jboss.com" wrote : 
  |   | Wrong.  Because you end up contorting your code to match the use-case of the dependency, rather than the use case you're trying to achieve, causing ineffective code to become further entrenched, and making it even harder to fix later.  
  |   | 
  | A?
  | What's the point of frameworks then?
  | 

They have no point, in and of themselves, unless they solve a specific problem without introducing more problems.  If the framework doesn't have a clearly defined contract, it is a problem.  If the framework's contract cannot possibly be met (aka VFS2), it's a defect waiting to happen.  If a framework doesn't have a strictly defined and limited scope it will eventually overlap and conflict with other frameworks.

"alesj" wrote : 
  | But well, now that I see your take on ext libs,
  | I'm no longer wondering why VFS3, vs. trying to fix existing impl.
  | 

Ales, the implementation can't be fixed because it's the API that is broken.  That's why the new solution is so much smaller.  It has a clearly defined API, with contracts that can be met by the implementation.  Yes there are implementation fixes as well, but it's fixing the API (and thus usage patterns) which gives us the performance increase and size decrease without compromising functionality.

"alesj" wrote : 
  | Wrong in what way?
  | Going back to AS4 behind an VFS api (aka VFS3) doesn't make it right. ;-)
  | 

I don't see what you're getting at here.


"alesj" wrote : "david.lloyd at jboss.com" wrote : 
  |   | Refactoring code is easy.  Refactoring semantics is really difficult (see VFS again).
  |   | 
  | Specially when you rename packages for no reason, right? ;-)
  | 

Huh?  Are you referring to VFS?  Renaming the package is just a one-key code refactor, it has nothing to do with semantics.

"alesj" wrote : 
  | I'm not saying you're completely wrong.
  | But in this case - as again my use-case proves it - 
  | I would never take that re-invented "reflection abstraction + resource lookup abstraction" over existing impls.

What if there was a substantial speed increase and memory footprint decrease associated with doing so?  That's the question I think we need to explore here.

"david.lloyd at jboss.com" wrote : 
  | We're here to solve problems, not worship old ineffective solutions.
You don't sound convincing, specially with all the negative comments about ext code.
Looks like you're more into re-writing things than solving real problems.
The world is not perfect, the code is not perfect,
but at least the code is open sourced, hence you can fix it. ;-)


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261323#4261323

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261323