reserved word or not ?

[jmburnod]

Hi All,
To cleaning my app i need to know if word 2 of a message which begin by "on" is s reserved word.
I tried
put ("mouseup" is reserved)
but i'm surprised that it return "false"
Thanks for your lights
Kind regard
Jean-Marc

[dunbarx]

Jean-marc.

I think the problem is that "reserved' is not reserved.

When you asked LC to evaluate "mouseup is reserved", it returned "false", just as if you asked "4 = 5".

Craig

[dunbarx]

Jean-Marc.

What is an example of a line of code that you are concerned about?

Craig

[jmburnod]

I want change all of my commands and functions to private handlers.
Something like that
"private command MyHandler" instead "on MyHandler"
The reason is that I am looking for a successor to maintain my app and I think it would be clearer if he can know right away if a handler comes from livecode or if it is a personal handler.
Klaus having introduced me to laziness , I wonder if one script using reserved word could do the job in the whole application.

Jean-Marc

[dunbarx]

Hmm.

Can you (untested):

Code: Select all

put the script of yourScript into temp
repeat for each line tLine in temp
if word 1 of tLine = "on" then replace "on" with "command" in tLine
put tLine & return after newSCript
set the script of yourScript to newScript

??

Craig

[jmburnod]

Hi Craig,
Yes, but with one more condition:

Code: Select all

if word 1 of tLine = "on" and word 2 of tLine is not a reserved word then replace "on" with "command" in tLine

Jean-Marc

[FourthWorld]

What will you do for functions?

[mwieder]

I don't think functions are going to be a problem.
You can get a list of the built-in functions by requesting "the functionnames", but if it's possible to override one of them (if for instance one is in a backscript or other library script) then it's something you've explicitly done.

The reserved words in question here fall more under the category of "messages", and there's no way I know of to get a list of the messages that are handled by the system. I'd love to have an easy way to get that list the way we can get the commandnames or functionnames. But there isn't one that I'm aware of.

[jacque]

The only thing I can think of is to somehow extract the content from the dictionary list and filter by type "message". Extracting from the dictionary would be the challenging part.

[FourthWorld]

I don't think functions are going to be a problem.
You can get a list of the built-in functions by requesting "the functionnames", but if it's possible to override one of them (if for instance one is in a backscript or other library script) then it's something you've explicitly done.

The reserved words in question here fall more under the category of "messages", and there's no way I know of to get a list of the messages that are handled by the system. I'd love to have an easy way to get that list the way we can get the commandnames or functionnames. But there isn't one that I'm aware of.

I put in a request for the messageNames a while back, but not many need it so I don't expect it soon.

But being able to identify function names wasn't the root of my question here. I was asking about what to do with them once identified.

In this thread, identification is just a means to an end, the end being to alter them to use the more distinctive "command" rather than "on" to provide an even more explicit identification for a future maintainer.

Personally, I wouldn't pursue that route. It's more work than needed, and we have no equivalent of "command" for functions anyway.

Far simpler would be to distinguish with capitalization: TitleCaps for custom names (big things attract the eye), and lowerCase for generic engine stuff (the stuff we see all the time will usually be less noteworthy over a maintenance lifecycle).

If a clear, concise, and simple method for distinguishing between engine stuff and custom stuff doesn't go far enough, you haven't found the right person for maintaining your legacy app.

PS: Be careful with "private". It's not just for distinguishing custom stuff. It limits scope so it can't be called by anything outside the script it's in. If that's what you need, then use it. But adding it wholesale in an automated way as described in the OP would likely yield many "handler not found" errors.

[mwieder]

But being able to identify function names wasn't the root of my question here. I was asking about what to do with them once identified.

Yes, and what I was trying to get at is... why do anything with them? There are two possible cases:
1. If they're functions you created then they're yours, not the system's.
2. If you're overriding a system function in a frontscript then again they're yours, which resolves to case 1.

And point taken about private handlers. I use them a lot, and would use more if callback messages didn't have to be public. But it does take care to avoid getting into trouble.

[FourthWorld]

Yes, and what I was trying to get at is... why do anything with them?

Seems we're on the same page. If custom naming conventions to distinguish custom things are good enough for Charles Simonyi they're good enough for me.

[jameshale]

The web API lists messages. According to the Dash docset there are 429 messages. If I remember correctly these should be in an sqlite db in the docset package. Or you can dive into the docset creator stack and just add a script snippet to write then out to a text file when you run it.

[jacque]

Far simpler would be to distinguish with capitalization: TitleCaps for custom names (big things attract the eye), and lowerCase for generic engine stuff

The issue wasn't how to represent the two, but rather how to identify them. The docset idea might work.

[FourthWorld]

Far simpler would be to distinguish with capitalization: TitleCaps for custom names (big things attract the eye), and lowerCase for generic engine stuff

The issue wasn't how to represent the two, but rather how to identify them.

Note why he wants to identify them:

I want change all of my commands and functions to private handlers.
Something like that
"private command MyHandler" instead "on MyHandler"
The reason is that I am looking for a successor to maintain my app and I think it would be clearer if he can know right away if a handler comes from livecode or if it is a personal handler.