On Sat, 10 Nov 2012, Sven Schreiber wrote:
On 11/10/2012 07:51 PM, Allin Cottrell wrote:
> 2) As Sven pointed out, if a function accepts a bundle argument -- in a
> context where the content of the bundle is not guaranteed to conform to
> a known schema -- the writer may need to determine (a) whether a given
> bundle contains an item corresponding to a certain key, and also (b) the
> type of the item, if present.
> OK, so rather than proliferating is*() functions for all types I
> suggested a more general typeof() function, which provoked suggestions
> and counter-suggestions from Jack and Sven. I'm now not so keen on that
> idea. If I'm right that the only serious use case for such testing is in
> unpacking bundles [see footnote],
This was just the first thing that I could think of. There may be other
use cases for the is*() functions. For example, say somebody has a
standalone script where at the top he has some global input, and the
script is written to cover all cases. Like:
<top of script>
matrix temp = I(2) # not commented out; active
# scalar temp = 1 # commented out; inactive
</top of script>
And further down in the script only the appropriate parts of the code
<do matrix stuff>
<do scalar stuff>
We may not like that programming style, but should hansl really be
changed to make this impossible, which has worked until now?
Well, since we don't have ismatrix() the exact example wouldn't
work, but I take your general point. The easiest way to support this
sort of thing would be to extend the set of is*() functions to cover
all types -- in their current form where the argument is a variable
name (or possible variable name).
> [footnote: Jack identified a third case where testing of a
> type could be useful, namely in working around bugs relating to the
> distinction between scalars and 1x1 matrices. I see that point, but I
> don't see it as sufficient reason for a fully general typeof() function
> if it's the only use case. When I got to thinking about it, I realized
> that implementing a general typeof() -- one that doesn't just accept a
> string argument (a putative variable name) -- would actually be quite
Well, AFAICS we have discussed checking variable names, not more.
Determining the type of a bundle content-item in advance requires
more than a variable name, but that's handled by the new version of
inbundle(), if we want to keep it.