[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: unassigned/untyped behaviour
From: |
M |
Subject: |
Re: unassigned/untyped behaviour |
Date: |
Wed, 22 Nov 2023 22:27:02 +0100 |
Il giorno mar 21 nov 2023 alle ore 20:32 <arnold@skeeve.com> ha scritto:
> Hi All.
>
> I finally took at look at this. "M", thanks for the
> report. Andy, thanks for the test case.
>
[...]
> Yes, there's a difference of behavior in that `a' is unassigned
> and `a[1]' becomes a number, but "fixing" that is next to impossible
> given the way Node_elem_new works. Forcing numeric or string
> type is the next best thing.
>
> I will work on the documentation. Here is a code fix
Hi, thanks for the fix!
I had imagined it would be complicated to "fix" the behaviour both in the
array and non-array cases, anyway how it works now is certainly clearer to
understand and to use.
thanks,
M.
--
me -> http://crap0101.altervista.org/
- Re: unassigned/untyped behaviour, (continued)
- Re: unassigned/untyped behaviour, arnold, 2023/11/21
- Re: unassigned/untyped behaviour, arnold, 2023/11/21
- Re: unassigned/untyped behaviour, Andrew J. Schorr, 2023/11/21
- Re: unassigned/untyped behaviour, arnold, 2023/11/21
- Re: unassigned/untyped behaviour, arnold, 2023/11/22
- Re: unassigned/untyped behaviour, Andrew J. Schorr, 2023/11/22
- Re: unassigned/untyped behaviour, arnold, 2023/11/22
- Re: unassigned/untyped behaviour, Andrew J. Schorr, 2023/11/22
- Re: unassigned/untyped behaviour,
M <=
- Re: unassigned/untyped behaviour, arnold, 2023/11/28