Same as many others on the octal question. Did not know/don’t use. (can see how it would be useful)
On this one... don’t use it for msg or envs. I rarely use by ref to change calling parameters, but do it now and again. I mostly use by ref for performance in loops or extraordinary large data sets. Ralph DiMola IT Director Evergreen Information Services [email protected] -----Original Message----- From: use-livecode [mailto:[email protected]] On Behalf Of Mark Waddingham via use-livecode Sent: Friday, June 10, 2022 3:45 AM To: How to use LiveCode Cc: Mark Waddingham Subject: Re: Would anyone miss convertOctals? On 2022-06-09 20:54, Craig Newman via use-livecode wrote: > Mark. > > Gong the other way, is your task made much simpler by losing > “converOctals”? I assume so, or the issue would never have come up. > Are there other similar language elements that also are on the block? I'm not sure it makes things 'much simpler' - but it does remove one thing to have to think about. Further it removes a case where script is ambiguous at parse-time - i.e. the token 0123 could mean one of two different things depending on a runtime property. Given the responses so far, it looks to me like convertOctals is an exceptionally rarely used feature (the number of years of LC experience amongst those who have responded is in excess of two centuries, and >80% of the respondents didn't know what the property was). Thus any added complexity caused by having this feature seems a waste of time/effort/mind-space - particularly as there is a more-than-adequate replacement which has none of its problems (i.e. 0o123) - and moreover one which other languages (e.g. JS) adopted a long time ago. In terms of other things which are 'on the block' - then no explicit features per-se but there are a couple of extreme 'edge cases' which will likely be removed. For example, the ability to use 'msg' (which is aliased to the content of the message box) and '$<envvar>' implicit variables as referenced parameters in handlers. Currently you can do: on mouseUp fillVars msg, $FOOBAR end mouseUp on fillVars @pA, @pB put "foo" into pA put "bar" into pB end fillVars The ability to pass these 'quasi-variables' as references will potentially reduce the potential performance gains of moving to a bytecode-based VM when referenced parameters are used in general, and thus (like convertOctals) their existence seems too high a price to pay for what is almost certainly a rarely used (if used at all) feature. Note: I should stress that the above is *just* removing the ability to pass 'msg' and environment variable globals as reference parameters to handlers *not* removing 'msg' or environment variables in general! Warmest Regards, Mark. -- Mark Waddingham ~ [email protected] ~ http://www.livecode.com/ LiveCode: Everyone can create apps _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
