To me a lot of FR issues pertaining to language enhancements deal with the wish to use abstractions to reduce lines of code to enhance productivity and readability.
If the compiler can implement a useful abstraction in a much more CPU efficient way than we developers could do by writing our own RB workarounds to "extend" the language, then such FRs are a good candidate to incorporated into the language. After all. We could all have written lots of iterator based stuff to handle "for each" before that keyword was added, but in many many cases that is a sledgehammer to crack a nut. Wisely, RB added For Each. I think my proposal for the "In" ( or 'IsIn" ) syntax a while back falls into the same category: If myvar In 1,2,3 then dosomething() End if Again many workarounds were proposed as objectuions, but they are all horrid, use up CPU cycles, or take up more lines of code than by using this new keyword. Sure one could write an IsIn function, but the compiler can implement this in the most CPU efficient way possible. On 26/3/07 16:20, "Norman Palardy" <[EMAIL PROTECTED]> wrote: > > 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> > Regards, Dan _______________________________________________________ www.13flatFIVE.com The C++ <> REALbasic code migration specialists _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
