Dragan,
< bg >

Following your logic, it's safe to say that VFP has multiple inheritance (dBase, SQL, VB) ;-)

>That's historical, and completely OOP because it was inherited :) from dBase II, which had two aliases, A and B (trying to run a memory.refresh() to check this...), and then came FoxPlus which had ten - and named them A to J. Then came FoxPro 1.0x which allowed for 25 and named them A to Z, but also allowed you to name them whatever you like. Well, so did FoxPlus (remember the alias->field notation?). Now why 25? Because the M alias was reserved for memory variables. Later versions of Fox pushed this further- to 255 in 2.0, to 32K in VFP. Thus, d.field would look for something named field in the table open in the fourth workarea. That's why you can always prefix a memvar with "m.", because that's the way to make sure it's not confused with a field with any alias. This also mean that
>m=CREATEOBJECT('form')
>?m.name
>will not work, but
>?m.m.name
>will (though Intellisense gets confused).
>
>Since the automatic aliases default to table names, will you ever see B,C, D and others? Well, you can:
>

create cursor whatever (field c(10))
>for i=1 to 300
>   use dbf("whatever") again in 0
>endfor
>set

>You will see one alias of Whatever, aliases B to J, and W11 to W300. These automatic aliases for special cases when a regular alias can't be made from the filename (doesn't begin with character or underscore) or when it already exists (like in example above).