James' point was not that he knows all, but that fixing fields is a low priority at the moment. The code base is in a somewhat awkward state while the SM is put into place the FI is fleshed out. Adding new features is also a low priority at the moment, so you can imagine that fixing something that almost no one uses is as well. Personally, I'm with James too; unless you have a specific use case, I'd go with properties. Property accesses will be inlined often as it is, and how common is it for "graphics" to be persisted? Shouldn't these graphical operations be taking place on a data structure kept in memory only? Well, I suppose I can't say I know what problem you are trying to solve but I can say that patches are always welcome. :)
On Sun, May 31, 2009 at 7:04 PM, hnk <[email protected]> wrote: > > Why not use fields? Nhibernate supports them and you can't say you > know all use-cases. In this case it's for graphics which according to > spec needs to be quick and fields allow me to optimize access to these > which will be called many hundreds of times per second. > > On May 23, 6:18 pm, James Gregory <[email protected]> wrote: > > It's a known issue, one that probably won't be fixed for a while either; > > it's an architectural issue that is fairly low priority compared to > > everything else. > > I'd personally recommend not using fields anyway, regardless of whether > FNH > > supports them or not. > > > > On Sat, May 23, 2009 at 6:06 PM, H F <[email protected]> wrote: > > > Hi, > > > > > Failing test. > > > > > Cheers > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Fluent NHibernate" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/fluent-nhibernate?hl=en -~----------~----~----~----~------~----~------~--~---
