on 28/3/02 10:51 PM, David Vaughan at [EMAIL PROTECTED] wrote:
> It was not the split that corrupted the container but your putting an array
> element into the same container as if it were not an array.
(Of course you're correct that the bug is not in split - that was a slip of
the keyboard.) But your suggestion that the bug was in me, not the code?
Is that like "guns don't kill people..." (oops, little bit of politics.
Stop now :-)
> your putting an array element into the same container as if it were not an
> array
It isn't an array. It's a container. A container which did have an array
assigned to it, and then had a string assigned.
Your suggested code (using 'combine' to make 'finfo' "back into a string"
before assigning to it) is completely unnecessary. The simpler workaround
("if I really _must_ keep using finfo as my sole variable") is
to replace
put finfo["happy"] into finfo
with
put finfo["happy"] into x
put x into finfo
I think it should be clear that by the second line, finfo hasn't changed.
It's still as you would say an array (actually, a container, containing an
array); and the value that gets assigned into it in the second line is a
simple string, as before; but this of course does not cause any corruption.
The problem is not that there is something wrong with assigning a value from
a container back into that container. The problem is in the engine. It's a
little bug.
Fundamentally,
put (expression) into (container)
should function correct regardless of what (expression) involves, or which
(container) is used.
> It just seems pretty inconsequential rather than nasty.
well I said "nasty _little_". I count it as nasty beause it's subtle:
depending on the actual code, the problem might not emerge until much
further down the program. If the compiler refused to parse this statement,
even though it was legal; or the engine threw an exception at it, even
though it was legal, it would be a little bug, and not nasty, because as
soon as you hit it you'd know. But I won't argue it's the worst thing I've
ever seen.
> your putting an array element into the same container as if it were not an
> array [...snip...] I would not have done that at any time because it seems to
> me poor practice to change the variable construct merely by a put action, even
> in a language not strongly typed. I excuse shifts between numbers and strings
> here, given the nature of the language.
Is it any better to change the 'variable construct' (by which I take it you
mean the type of the value) by a split action or a combine action? I
personally would have preferred to see 'split' and 'combine' work as
expressions returning a value, eg
split finfo by comma and space into finfoArray
FWIW, I find
put finfo[x] into finfo
clearer - in that we know that a new different value is being put into
finfo.
> I would not have done that at any time because it seems to me poor practice to
> change the variable construct merely by a put action, even in a language not
> strongly typed. I excuse shifts between numbers and strings here, given the
> nature of the language.
I also practise cleaner use of variables, including hungarian notation,
where appropriate (by which I mean in longer more complex function
definitions); but in such cases I may separate variables not just by array
and string, but by array, string, number, boolean.... and indeed by meaning.
But equally there are some small tight functions where I don't find this
necessary. The real version of this function was more like (I'm typing from
memory here):
function fileInfo path
set the itemdelimiter to "/"
set the defaultFolder to item 1 to -2 of path
put urlEncode(last item of path) into fname
put the detailed files into finfo
split finfo by return and comma
put finfo[fname] into finfo
return finfo
end fileInfo
(Please don't point out I could just return the result of the final
expression directly! The real code took an optional second parameter to
select a particular piece of information, eg the modified date or resource
fork size, so there were a few more lines after the return).
At each of these lines, 'finfo' contains file info - first on a bunch of
files in one format, then on a bunch of files in another format, then on a
single file in close to the first format. At each line, it is necessary to
know what format it is in - it's not enough just to know "it's a string".
The fact that for the space of one statement the finfo contains an array
does not seem to me the most interesting thing about it.
Ben Rubinstein | Email: [EMAIL PROTECTED]
Cognitive Applications Ltd | Phone: +44 (0)1273-821600
http://www.cogapp.com | Fax : +44 (0)1273-728866
_______________________________________________
improve-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/improve-revolution
