Telling tables what their fields are

[Ed Kleban]

On 11/19/05 12:20 AM, "Ruslan Zasukhin" <sunshine at public.kherson.ua> wrote:

> On 11/19/05 12:54 AM, "Ed Kleban" <Ed at Kleban.com> wrote:
> 
> Hi Ed,
>  
>> All of the Classes_way examples declare properties of the appropriate VField
>> subclass, and then have a constructor method that employs a constructor for
>> each field using a form such as:
>> 
>>     mfBornDate = new VDate( "fldBornDate" )
> 
> right
>  
>> As a result, you can access the VField methods for a table using the VTable
>> subclass properties, but not by using any of the VTable methods, since at
>> the VTable class level, the code is clues of what fields may have been
>> defined.  
> 
> Right, and THIS IS the main advantage of Class way
>  
>     * you avoid a lots lines in your code as
>         Table.Field( "xxxx" )
>         
>       so this affect performance.
> 

Yes. Understood.  That's a good thing!

>> Thus inquries such as:
>> 
>>     mfBornDate.Table returns what?   Nil I suppose.
> 
> No of course. :-)
> 
> It returns Table where you have create fields.
> How it works?
> 
> Constructor of Vtable work BEFORE start work constructors of fields,
> So in background it set one global pointer. (inside of plugin)

Eeek!  So... hmm.  So, presumably Tables are associated with a database in a
similar manner with a different hidden global variable.  Therefore:

1) All Tables created with "new VTableClass(...)" AFTER a database is
created via "new VDatabaseClass(...)" are automatically associated with the
last created database.

2) All Fields created with "new VFieldClass(...)" AFTER a table is created
via "new VTableClass(...)" are automatically associated with the last
created table.

3) The call pattern documented in the example where a Database constructor
creates its tables and Table constructors create their fields, makes this a
natural order of occurrence by virtue of defining and instantiating classes.

If true, then yeah... I get it.  It's very clever, indeed very elegant.  For
my personal tastes perhaps a bit too clever.  I'm not sure I entirely like
it.  But I get it.

I would prefer to see Table constructors that take an optional Database
argument, and Field constructors that take an optional Table argument, and
when no argument or nil was supplied defaults to the behavior that you've
implemented but essentially have hidden.  That would allow more complex
definition strategies whereby you don't necessary have to define tables and
fields in the order your methods mandate -- but still could.  More
importantly it would give the coder the option of explicitly including the
arguments even if they were not needed by virtue of being identical to the
defaults, so that: 1) The code would be more readable and 2) It would be
absolutely explicit what was going on and that Tables were being linked with
Databases and Fields with Tables.

But I get it and can work with it now that I understand it.   Thanks!

You should DEFINITELY include this in the documentation.   Please  :)
    
> 
>> This can presumably be fixed by instead declaring the new VField instances
>> using something like:
>> 
>>     mfBornDate = self.CreateDateField( "fldBornDate" )
>> 
>> which would then allow you to successfully use inquiries such as:
>>     
>>     mfBornDate.Table
>> 
>> Is there anything wrong with this approach?
> 
> STOP STOP STOP.
> 
> You guess or you really see that .Table  returns nil ????

Haven't seen it, it was just a guess.  Clearly a wrong guess.  Thanks for
the enlightenment.

> It should work correctly.
> 
> 

I believe you.

Thanks!
--Ed