On 06/26/2017 11:48 AM, Mark Waddingham via use-livecode wrote:
I'm against synonyms being part of the core language - they have no place there 
as they are 'tailorings'. Indeed a good part of the argument for them could be 
solved by better tooling - e.g. autocomplete and suggested tokens if one isn't 
quite right.

Heh. Autocomplete, I think, works well when you already have an idea where you're going. I don't think it would help much with a line like

"if x "

You and I have this discussion about synonyms regularly, and I don't expect that either of us will ever convince the other. I'm happy that you are the one in charge of shepherding the language, and I'll continue my role as proponent from the sidelines.


Every single property in the engine could have synonyms and some many (see the 
recent discussion about clipsToRect). An attempt to 'normalise' hilite and its 
various compound forms would have resulted in 40 (iirc) additions to the token 
table.

My PR for 'hilite' wasn't to 'normalise' the term, but to be consistent about its use. To this day I can't remember where 'highlight' is acceptable and where 'hilite' is proscribed, my distaste for 'hilite' as a word notwithstanding.

Moreover every single synonym reduces the set of possibilities of things we 
could add in the future and can cause backwards compatibility issues in 
existing scripts (as they become for all intents and purposes reserved).

Point taken, but do you seriously believe it would be a good idea to have different meanings for "hilite" and "highlight"? I can't imagine that repurposing either of these for the same syntax would help in anyone's comprehension of the language or ease in scripting. Making the two words synonyms is the only thing that makes sense to me.

There is no easy way to administer synonym additions centrally and each one 
increases the maintenance burden in the current architecture.

Having submitted several rejected PRs for synonyms I can vouch for the fact that they're not that hard to add.

So, I get the reasoning behind them (although I still think it better to train 
people implicitly to use canonical forms via better tooling, as if everyone 
'sings' with the same language, uniform understanding is increased) so in the 
future everyone will be able to 'knock themselves out'...

That may be the basis of our disagreement then... I'd prefer that everyone *not* be stamped from the same mold.

--
 Mark Wieder
 ahsoftw...@gmail.com

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

Reply via email to