On 2015-10-27 03:07, Mark Wieder wrote:
Well. *This* certainly seems to have hit a nerve.
Indeed - perhaps a little bit - but honestly not with you!
Your pull request is a good one - it is minimal, focused and has
tests... Tests the writing of which uncovered two bugs which need to be
fixed in the engine. As PRs go, I couldn't really ask for much more.
However, the problem is that it attempts to 'fix' something which I
think needs a little more thought about what the policy should be before
it is 'fixed' - as it sets a precedent, the potential consequences of
which are a combinatorial explosion in keywords.
I would be fine with having everything be "hilite". Or with everything
being "highlight". Or with everything being "blxxqvy". The point of
the original bug report was that there's no consistency in the
language. Sometimes you can use the "highlight" form and sometimes you
have to use the "hilite" form. The problem is trying to remember which
is which.
Indeed, I want consistency - however, going from a situation where
things are inconsistent, and lax to one where they are consistent and
strict-enough is really difficult to do piece-meal when you have
literally millions of lines of code out there which depend on the
current implementation.
I agree with what you're saying about the proliferation of synonyms.
I'm not wild about most of the other synonyms in the language
either... "cd", "fld", etc (although I'd hate to give up "loc" and
"rect") But right now we're trying to have it both ways. To my eye the
"hilite" form looks cutesy and unprofessional, but I do understand
developers are lazy and don't like typing, so I'd be fine with that.
It's in the documentation already.
I'd prefer 'highlight' too - but with any long standing system which has
evolved over a long time you have to respect the 'defacto standards'
which have evolved within it, whether intended or unintended as a great
many people will have learnt to depend on them.
But really... let's move in the direction of some consistency.
Definitely. We just need to make sure we work out the best way to get
there.
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
