From: Nando D. <na...@de...> - 2005-08-18 18:51:45
|
Michael, >> Personally, I'd very much like to see some universal persistent >> solution. If it cannot be done or isn't useful for frames, then let's >> go with Milan's Base class, although I'd like to point out that I >> don't think it's buying us much except a bit of style over the >> current solution. M> But I thought you like to do things in good style? I am usually most concerned about flexibility, simplicity and capability of a design to adapt to changes (not that I achieve those every time, not even close, yet I always try). It might seem it's mere style, but it's really more pragmatic. ;-) Anyway, I like the idea of an object registry. I just said I'd prefer a persistence-enabled solution if feasible. M> A universal persistent solution is possible with string handles (item M> paths). or URIs, now that you make me think about it... M> But there is something to say for using the right tool for the M> job, and shoehorning everything to use a string handle where an integer M> handle would be sufficient does not appeal to me. It might be a valid concern, although... See below. M> Operations with integers (searching for, comparing against) are M> just much more convenient and efficient. I'm not going to argue that string comparisons are as efficient as integer comparisons <g>, but can you tell the difference from the user POV? Can you measure it? The scoping feature in Config has the potential to cause dozens of *file accesses* each time you open a frame. This is thousands of times less cheap than a string comparison, yet nobody objected for that. :-) I say let's find the design that suits our needs, then we implement it, then we time it and lastly we optimize it. I repeat I'm not sure persistence is vital for frames, I'd just like to have a unified mechanism for everything. M> 1) Persistence as detailed above. I agree with you here, also with your M> ideas about scoping etc. OK. M> 2) Identification of DBH objects and frames in URIs. I see at least M> three reasons for using a handle instead of the address: M> - it is slightly higher level, and can be implemented in a clean way M> regardless of OS, processor architecture and pointer size. M> - references to already destroyed objects are less likely. ...and in any case one of them wouldn't result in a crash. M> - a reallocation of an object (same handle, but different address) can M> be realized, which is handy for e.g. the proxy pattern. This is M> somewhat close to the first point, but within the same session. Completely agree. We need to get those identifiers to a higher level. M> 3) Finding an object that matches certain criteria. FrameManager does M> this right now, it allows to check for a property frame for a given DBH M> object. But the current implementation is way too specialized, finding M> other frames or different kinds of property frames for the same object M> would need changes to the FrameManager class. M> This would be easily extendable if one could enumerate all frames and M> compare against their item paths. Something like M> "propertyframe::DATABASE::employee.fdb::TABLE::employees::TRIGGERS" M> would be ideal to check for just the right frame. OTOH with item paths M> that long these should not be part of URIs. All of this has to be M> parsed by the HTML control, so why slow things down artificially? A concise and right-to-the-point summary. I certainly will think about it. Ciao -- Nando Dessena http://www.flamerobin.org |