[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compare 2 arrays.

From: Bill Gradwohl
Subject: Re: Compare 2 arrays.
Date: Wed, 30 May 2012 12:28:44 -0600

On Wed, May 30, 2012 at 10:57 AM, Greg Wooledge <address@hidden> wrote:

> There are plenty of things that occupy that middle
> ground -- unexpected program behaviors.  The programmer can never
> anticipate *every* input sequence that users will throw at the software,
> so some of them may cause surprises.
> True enough!

Where is it written that this is not legitimate? Where is it written that
it is? In the absence of formal documentation one way or the other, the
product itself arbitrates the matter. In this case bash says its legit
because it works.

Once something has been identified as belonging in that gray area, a
determination has to be made one way or the other as to what to do about
it. Leaving it unresolved adds uncertainty which is never a good thing.

Clearly this "feature" is a needed part of the language. Coding around its
non existence is either impossible in your case or as you say, a hack in
mine. So do we simply stop and hold our collective breath till X number of
releases go by to see what happened or do we get a determination? I would
prefer something cleaner and well documented, but I'll use what is
available till then.

To change bash to search out the existing capability and stop it would be
counter productive. The same effort could probably provide a documented new
feature similar to nameref in ksh. I'd use that feature in an instant if it
were available.

The danger of using unexpected program behaviors in your applications
> is that the behaviors may change without warning in a future version of
> the program.  The programmer may not even be aware that this behavior
> exists, let alone that people are using it.  A clean-up of the parser
> (or similar change) may make the behavior go away, or change.
You say it's unexpected behavior. I'll agree it's using what the product
provides in a way that isn't obvious, but why is that necessarily bad? If
it goes away in the future, I expect it will do so because something
documented replaced it. Progress demands that the next release should be at
least as capable as the current one and since the current one provides
access to a foreign array as I demonstrated, the next release should also.
Hopefully well documented.

Using the tool you have now and doing something is better than waiting and
doing nothing in the interim.

Bill Gradwohl

reply via email to

[Prev in Thread] Current Thread [Next in Thread]