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