On Thursday 05 Apr 2012 23:49:04 Zlatin Balevsky wrote:
> > If your 'solution' is trading 'jar
> > size' and 'readability' against run-time performance (for the common
> > case assuming logNORMAL), we won't merge it. Freenet is slow enough
> > as is.
>
> Any patch with lazy evaluation will not cause problems in the "normal"
> case but will affect debugging Fred because turning on debug log level
> for a single class will cause all lazy parameters everywhere to be
> created. Imagine you're trying to reproduce a rare bug and have
> turned on one or two debug statements - because of lazy evaluation
> your jvm will garbage collect much more often and you may never
> reproduce the bug. This is valid for current generation jvms.
>
> > Hint: your doing it wrong, the one way to make it faster and nicer is to
> > use dependancy injection
>
> DI is generally great but it doesn't solve the problem of "ugly
> predicate". You're better off looking at some bytecode weaving
> techniques like aspects. Combined with DI they can make the code very
> clean.
Whatever the interface is, the Right Way is to introduce the predicates at run
time. (Assuming that doesn't affect debuggability and doesn't significantly
slow loading). It may be possible to do this with the bytecode manipulation
library provided by db4o, which it uses for optimising native queries (queries
expressed as function(object) { return true if we want it }). On the other hand
it's quite heavyweight, which is why we don't generally use native queries...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20120406/017d7634/attachment.pgp>
