Sorry, I misunderstood your intentions. Now I can see the advantages of your approach: a developer has to implement the whole interface only if he/she needs to have more control over some features. This sounds great to me!
Lorenzo Nicolás Lichtmaier wrote: > >> sorry to re-open this thread, but I am facing the same problem of >> Nicolás. >> I like both yours (Doğacan) and Nicolas' ideas, more yours as I think >> abstract >> classes are not good extension points. > > That wasn't what I had proposed. My suggestion was to use an > interface, as always, but made this API real clean, expressing the > minimum the rest of the code needs from a scoring plugin, removing > assumptions about its implementation. Then I've proposed to have an > abstract class, implementing this interface, with a skeleton for any > class which works "distributing score to outlinks". So we would have > the best of both worlds: People creating new "PageRank" algorithms > wouldn't need to reimplement anuything, they would just subclass the > abstract class. And people like you and me would directly implement > the interface (or use a different abstract class if there's common > logic to share). My boss put all of this on hold, but I'd like to > implement this idea in a near future and try to have it included in > Nutch. > > > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Nutch-developers mailing list Nutch-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nutch-developers