On 2015-10-24 22:47, Mark Wieder wrote:
On 10/24/2015 12:21 PM, Peter TB Brett wrote:
* hilite -> highlight
Actually I filed a bug report on that six years ago.
http://quality.runrev.com/show_bug.cgi?id=8211
It got confirmed and ignored.
I just submitted a pull request.
Figured I might as well fix this myself.
There's a slippery slope here (in terms of the current engine parsing
implementation at least) which means that just adding synonyms because
the lack of them 'annoy' a small set of people (and/or because you can)
really isn't something which makes sense.
It is clear that originally 'hilite' was the chosen spelling for that
operation - it is an 'informal' spelling of 'highlight' which has been
historically used in GUI frameworks (probably because it is a good deal
shorter than 'highlight' - something which those who are fond of 'grp',
'fld', 'ac, 'cd' etc. should feel at home with ;))
There was obviously clearly some contention over whether 'dehilite' or
'unhilite' should be the antonym - given that even 'dehighlight' nor
'unhighlight' tend to appear in dictionaries this is probably not
surprising.
So, clearly someone 'complained' at some point (which is probably why
dehilite and unhilite both exist) and 'highlight' was added. Indeed,
there are actually the following fundamental synonyms for 'hilite' in
the engine:
- highlight
- highlighted
- highlite
- highlited
- hilite
- hilited
So that is 6 ways to write exactly the same thing. (It gets better in a
moment)
We now have the following 'compound' property names involving 'hilite':
- hiliteborder
- hilitecolor
- hilitefill
- hiliteicon
- hilitepattern
- hilitepixel
We also have the following 'compound' property names involving
'hilited':
- hilitedbutton
- hilitedbuttonid
- hilitedbuttonname
- hilitedicon
- hilitedline
- hilitedtext
There are also the following 'other' properties:
- autohilight
- autohilite
- linkhilitecolor
- multiplehilites
- noncontiguoushilites
- sharedhilite
- showhilite
- threedhilite
- togglehilites
So, there are (in fact) the following variations on 'hilite' currently
in use in the engine:
- hilite
- highlite
- hilight
- highlight
Which, if accounted for in synonyms would mean we would end up with (I
believe) 72 keywords if we ignore the 'ed' forms, and 144 if we have
both the preset and past participles. Also, it means that every time
anyone wants to add a property containing 'hilite', they need to add 4
(maybe 8) variants. This kind of 'blow-up' suggests that there is
something wrong with the approach.
So, I do think that in this case it would be far better to *choose* what
variant spelling is the normative one and deprecate all the other
synonyms at least until there is a much better mechanism in place for
parsing and resolving synonyms (i.e. when compound properties are
specified as separate words, and synonyms are substitutions done as a
pre-processing step).
For anything like there has to a policy and my policy has always been -
you choose a single representative for a single concept and you stick to
it. In this case 'hilite' is a perfectly valid word to use (given its
domain - i.e. GUIs); indeed, it is just as valid a choice for
'highlight' as 'color' is for 'colour' and 'behavior' is for
'behaviour'. At the end of the day this is a computer language and as
such logical and sensible choices have to be made. (One could also argue
that the problem of synonyms and abbreviations is far better handled in
the script-editing environment... Although nobody ever seems to agree
with me on that one - even though the resulting effect would be
identical for all intents and purposes ;)).
Now, I'm not saying this won't change - clearly there is a want for
synonyms as a fair few people seem quite fond of them. However, there
needs to be a good mechanism in place to deal with them in the engine
and there currently is not (particularly when considering compound
forms) so caution is hugely advisable.
Warmest Regards,
Mark.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
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
