Geoff Canyon wrote:
> To me, this is very much like the following, which works:
>
> put "test" into x
> put z before char 7 of x
> put x -- puts "testz"
>
> There is no character 7 of x. The length of x is 4 (and then 5,
> obviously). The engine takes an unexpected input and interprets it in
> a sensible, predictable, and useful way. Interestingly, this does
> something quite different:
>
> put "1,2,3" into x
> put 4 before item 7 of x
> put x -- puts "1,2,3,,,,4"
>
> In this case, since empty items are possible, the list is padded to
> make the command possible in a stricter sense than what was possible
> with characters. I doubt I'm demonstrating anything obscure here, but
> I'm trying to illustrate one of the beautiful things about LC: in many
> circumstances, it simply "does the right thing," even when given
> potentially counterintuitive input. I'd hate to lose that.
Did you mean to post that in reply to the other thread on delimiters?
Neither of those examples are of tabStops.
The tabStops issue is distinguished from those by one key principle:
Whether we prefer the behavior those examples exhibit or not, the
behavior is consistently applied, regardless of the values in the data
being acted on.
But with tabStops, the behavior differs with different data.
That's a big ouch, making it impossible to write a handler which can
reliably automate the setting of tabStops if the range of values is
sufficiently dynamic.
Sure, it's been around for a long time. So has "destroyStack", which
doesn't destroy a stack. I think the world of Dr. Raney, but I think
he'd be the first to say that sometime he took short cuts (ever hear the
one about how the boundingRect property was first implemented in a
different order from all other rects in the language?).
In this case, the convenience once offered by having this one token
crudely attempt to serve two different goals was fixed with tabWidths,
which supports relative offsets consistently and reliably.
That said, I agree here with the one thing this has in common with the
delimiter thread:
> Further, I think all the arguments against changing the behavior of
> the terminating itemdelimiter apply here as well: given the long
> history of this behavior, changing it is risky for existing code.
I seem to be in a minority when it comes to changing the behavior of
tokens that have been in the language for a long time, but it's
encouraging to see that number growing.
As I noted earlier:
But before I file a bug report, let's see if it's worth the time:
has anyone ever had code that produced unexpected/unwanted results
from this inconsistent treatment of the input values of tabStops?
So far we've only heard from Peter on this. Maybe there are others, but
maybe there aren't.
There are enough dumb things in the language that I don't think anyone
wants to see RunRev take time away from more critical things to address
them all.
So I won't file this as a bug report until there's evidence that it's as
problematic in practice as it is in theory. And even then, there's
certainly no reason to believe that if I did file a bug report anyone
would bother with it in light of the bigger goals they're working on
right now.
If it's a problem it can be fixed. And if it's not a problem this
thread will die a natural death. :)
--
Richard Gaskin
Fourth World Systems
Software Design and Development for Desktop, Mobile, and Web
____________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.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
