"George Moschovitis" <george.moschovitis / gmail.com> schrieb im Newsbeitrag
news:1096307995.391383.313070 / k26g2000oda.googlegroups.com...
> Robert,
>
> first of all, thank you for your comments!
>
> > difficult to track down since nobody expects this (if it's done
> > automatically)
>
> this is not done automatically, the programmer explicitly
> includes a Mixin.
>
> > You're likely to run into name clashes and such
>
> only lru_next/lru_prev/lru_key are added to the class to be cached,
> I think name clashes are very unlikely.

I think otherwise.  But this is a free country. :-)

> > Using an Array as list storage comes to mind.
>
> This was the original method used, but in order to make this
> efficient I had to use lookup by pointer AND a lookup by the
> caching key, so I swtiched to a custom structure. If you can
> adapt the code to use an Array and no mixin, I will be
> impressed :)

Yeah, true.  Drop the array suggestion.

> Your last idea is rather interesting, but the gain (no mixin) does not
> justify the complexity.

What do you mean by complexity?  Storing a single linked list element is
not really something I'd call "complex".

> I use this cache in a simple Fragment caching
> scheme for web applications and it seems perfectly natural to
> write code like:
>
> class Fragment
> include N::LRUCache::Item
> attr_accessor :body, :last_modified, :expires
> ...
> end

*I* would not find this natural.  If I were using a LRU cache I'd only
expect to have to provide keys that satisfy the same conditions as Hash
keys (immutable, proper #hash, #eql? etc.) and nothing more.  Everything
else makes things unnecessary complicated.

A simple calculation might explain this: if you have the choice of
increasing the complexity in a framework or std lib vs. increasing the
complexity in clients of this framework / lib, the lib side increase
usually generates overall *less* cost than the client side increase simply
because there are usually multiple clients using the same framework / lib
and *each* pays the complexity penalty (which consists of coding efforts,
testing and probably documenting).  So if you want to make life easy for
people that you want to use your lib / framework do invest the extra
effort; this will increase the likelyhood of your piece of software being
chosen over some other piece of software.

Regards

    robert