On Mar 26, 2007, at 9:02 AM, Daniel Stenning wrote: > Just because that's how Ruby and others implement it doesn't mean > RS has to. > Those tuple solutions have a lot of code overhead.
Those just happen to be pointed to as the model for how it should work so I was just pointing out that they really do more than what is claimed > One way RS could implement this internally is - as I said - to use > "invisible" RB structures as the return value and do the necessary > unpacking > behind the scenes. This would avoid the added CPU overhead due to > having to > deal with the genericity and abstraction of tuples. Certainly they could implement it in any one of several ways I can imagine at least a couple some of which should preserve type safety > In addition, since such a struct would be "invisible" I cant see a > reason > why this struct could not also be able to embed stuff that normally > cannnot > be included in a RB structure, such as class references or array > references > - in whatever smart-pointer data format RB references are stored. If a variant could hold a reference to an array it would already work but it would not be type safe. If there were a way to make that type safe an internal dictionary would suffice. I'm sure that if REAL ever does decide to do this that they'll have other ways and means to achieve it. I'm just not convinced that we cannot already do something that achieves most of what is requested. _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
