bug-gawk
[Top][All Lists]
Advanced

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

Re: [bug-gawk] array initialization


From: arnold
Subject: Re: [bug-gawk] array initialization
Date: Sat, 05 Jan 2019 11:29:15 -0700
User-agent: Heirloom mailx 12.5 7/5/10

Hi Andy.

Coding while sick is probably not a good idea.  Get some rest.

"Andrew J. Schorr" <address@hidden> wrote:

> On Sat, Jan 05, 2019 at 09:57:56AM +0100, Wolfgang Laun wrote:
> > IMH, it would be preferable if you can avoid burdening the user with 
> > thinking
> > about getting some optimum _implementation._

Absolutely correct.  The multiple implementations are internal implementation
details that could change at any time and thus are purposely not
documented. I want them to stay that way.

> > Idea: whenever the last element of an array is deleted, revert its type to
> > "null". The element added next will select the new type.

See other mails. I think this is reasonable, but again, should not
be documented.

> It remains difficult to debug these types of issues because typeof doesn't 
> shed
> any light on the backend array type. One could imagine adding an optional
> second argument to typeof that will contain an array returning various
> attributes of the variable, with no guarantee of stability across releases.
> The array could contain various attributes with information about the internal
> representation of the variable. I don't believe this can be done in an
> extension because the implementation details are hidden by the API.

I'm OK with this, a long as the doc is VERY clear that the contents of
the array can change from release to release and is there mainly for
debugging purposes.

Or you could add more info to the existing debugging adump() function
and use that.


Arnold



reply via email to

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