xTalk Interpretation Differences
Posted: Sun Feb 13, 2022 11:16 pm
Everyone here probably already knows that the original xTalk, HyperCard HyperTalk interpreter was extremely forgiving as far as flagging bad syntax, which most developer people would likely say is a bad thing (one might argue that this is part of why it was an even better xTalk for beginners programming, but I digress).
I've recently discovered that the 'feature' of this looseness that I really miss from HyperTalk's interpretation of xTalk, one that the LCC/OXT engines doesn't (currently) allow, is that it...
Allowed you to replace/override/or otherwise handle built-in messages, commands and functions before they get to 'the engine'!
So for example one could easily handle, let's say the 'play' command, to use their custom 'on play' command script in their stack or library, instead of, or in addition to (va 'pass' keyword), the engine's internal 'play' command. This would allow you to make players for custom data types... maybe .mod file player, or .flac files or whatever type. you could have syntax like
on play pMediaType,pMediaRef
and use it like:
play flac pFLACFilePath or play mod pModFilePath
just as there is...
play audioClip pAudioClip or play vc pMyMoviePath
To me this is THE use case MetaCard's author should have accepted for allowing it.
It's the same use-case as it is in other object-oriented programing (at least in Objective C), you can take a 'class' and make a copy class from it, modifying it into a custom class then get your app to use that instead of the original class, perhaps overriding aspects of the original that was used as the template. The 'class' template in the 'play' example is simply a standard xtalk 'message' type handler. Basically I'm saying internal commands and functions, at least certain very broadly applicable ones like 'play', should betrayed like class objects.
I've recently discovered that the 'feature' of this looseness that I really miss from HyperTalk's interpretation of xTalk, one that the LCC/OXT engines doesn't (currently) allow, is that it...
Allowed you to replace/override/or otherwise handle built-in messages, commands and functions before they get to 'the engine'!
So for example one could easily handle, let's say the 'play' command, to use their custom 'on play' command script in their stack or library, instead of, or in addition to (va 'pass' keyword), the engine's internal 'play' command. This would allow you to make players for custom data types... maybe .mod file player, or .flac files or whatever type. you could have syntax like
on play pMediaType,pMediaRef
and use it like:
play flac pFLACFilePath or play mod pModFilePath
just as there is...
play audioClip pAudioClip or play vc pMyMoviePath
To me this is THE use case MetaCard's author should have accepted for allowing it.
It's the same use-case as it is in other object-oriented programing (at least in Objective C), you can take a 'class' and make a copy class from it, modifying it into a custom class then get your app to use that instead of the original class, perhaps overriding aspects of the original that was used as the template. The 'class' template in the 'play' example is simply a standard xtalk 'message' type handler. Basically I'm saying internal commands and functions, at least certain very broadly applicable ones like 'play', should betrayed like class objects.