Ptr namespacing is kinda horked

While looking more in-depth at a recent bug report, I realized that we have a fundamental flaw in the way the Ptr magic namespace works. I'm talking about the way that you're able to easily peek and poke values with a Ptr via a magic dataype name. The idea is an honorable one in that it fits nicely with the "easy to use, but still powerful" mantra that REALbasic follows. But due to the left-associative nature of the dot operator, this concept has some flaws.

Consider the following snippet of code:

Dim p as Ptr = SomethingThatReturnsAPtr()

p.Int32 = 21

This code demonstrates the magical namespace in all of its glory. What happens is that the scope lookup operation in the compiler sees "p", and knows it's a Ptr. Then it sees "." followed by an identifier. So it looks on Ptr to see what Int32 is, and it turns out that Int32 is perfectly valid to work with. Yay, life is good, and this is a very easy and readable way to deal with Ptrs. Now, consider this snippet instead:

Module Test

  Global Structure Wahoo

    i as Integer

  End Structure

End Module


dim p as Ptr = SomethingThatReturnsAPtr()

p.Wahoo.i = 12

In this case, the scope lookup operator finds "p", knows that it's a Ptr. Then it sees a dot followed by Wahoo. Wahoo is a valid datatype for Ptr to work with, and so the next thing we find is another dot followed by "i". i is a valid member of the Wahoo structure, and so we're good to go. Again, this all works nicely and is very readable. But let's change the snippet a little bit.

Module Test

  Public Structure Wahoo

    i as Integer

  End Structure

End Module


dim p as Ptr = SomethingThatReturnsAPtr()

p.Test.Wahoo.i = 12

In this case, we've made the structure Public instead of Global. So in order to access it via the Ptr, we naturally put in "Test.Wahoo" instead of just "Wahoo" so that we have the properly qualified name. But this is where left-associativity in the dot operator kills us. We find p, and we know it's a ptr. But then we find "Test", and that's not something that's legal on a Ptr. Heck, it's not even a type! So we fail because there's no such thing as a p.Test in the world. This is why the Ptr namespace concept is fundamentally flawed. When using items accessible via the current namespace level in an unqualified manner, everything is fine. But as soon as you have to start qualifying the names, it's going to fall apart.

One way to try to deal with this would be to add new magic methods onto the Ptr namespace that are familiar to anyone with a BASIC background: Peek and Poke. Something that would allow you to say:

somePtr.Poke( SomeClass.SomeStructure.SomeField, 12 )

In this manner, we can always assume that the first parameter to Poke (and the only parameter to Peek) is a datatype which may or may not be a fully-qualified namespace. Of course, you should still be able to do this (for consistency's sake):

dim i as Integer = somePtr.Peek( Integer )

The tricky part about this is the grammar for it. Nowhere else in the language is there the idea of a datatype field like this. CType comes close in that it assumes you'll get the datatype. But, in that case, it would get you to the structure (since that's a datatype), but not the field (which is the interesting bit, since we require the field's size information). So we'd have to come up with an entirely new grammatical representation for this oddball concept, which is very heavy-handed.

Another way to do this is to treat Peek and Poke like CType in that they don't deal with typed sizes, they deal with datatypes. So, for instance, you wouldn't go down to the structure field level within the call to Peek or Poke. Instead, you'd tell Peek and Poke "this is the datatype I want you to use." For instance:

dim i as Integer = somePtr.Peek( SomeClass.SomeStructure ).SomeField

This way, the grammar can continue to use the concept of a datatype like CType, type casting and IsA. The downside to this is that it might be confusing to users because it doesn't behave like the imported namespace functionality. The upside is that it's a cleaner implementation!

So yeah, something for me to continue mulling over. But the take-home point for you is to understand that Ptr and namespaces don't mix. It's not a bug that they don't mix, it's just a design shortcoming. The only way for you to work around the design flaw is to ensure that there's no namespace involved, then Ptr can work with the datatypes.