Would anyone miss convertOctals?

[Ralph DiMola]

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
rdimola at evergreeninfo.net

-----Original Message-----
From: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] 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 ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
use-livecode at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode