|Perl: the Markov chain saw|
Re: A Tricky Problem with Contextby RSevrinsky (Scribe)
|on Apr 08, 2002 at 08:37 UTC||Need Help??|
I don't think that a second parse or using tie would make any difference here. Bear in mind that Visual Basic is not that smart either. I also thought that an unexplicitly-defined variable, like x in your example, is treated by VB as the omnivorous Variant, but MSDN claims that it automatically becomes an object. Strange -- that might be a difference between VB6 and VB.NET.
You are clearly building your own namespace table -- that's how you determined in the first example that x was an array. In nonstrict code, you're just going to have to determine a variable's type based on assignment. In the second example, that's not too difficult: split would imply an array. But what if the unknown Object is returned from a function:
Now, in this case, there's no way of knowing until runtime whether FetchSomethingStrange is going to return a String or an array. That leaves you with 2 options (as I see it):
The listrefs would translate your nonstrict code as follows:
My code translates well, too:
Again, you should be fine as long as the Perl translation is always talking in scalars, be they adapted VB scalars (String, Integer, Double) , Variant or Object types, or listrefs derived from Variant/Object auto-arrays or even from explicitly Dimed arrays.