Telling tables what their fields are

[Ruslan Zasukhin]

On 11/19/05 3:08 PM, "Ed Kleban" <Ed at Kleban.com> wrote:

>> 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.

Yes right.

> For my personal tastes perhaps a bit too clever.  I'm not sure I entirely like
> it.  But I get it.

Well, you can use just API way. But if you will start code with API way you
may very fast note many repeated lines of code. If you will start to think
how avoid them, you will come to above model.
 
> 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.

I will try explain below WHY such and only such order if offered.

> 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.

:-) 

Hey man! I have spend probably 10 long minutes inventing this mechanism of
"hidden variables", exactly to avoid this parameter!

> But I get it and can work with it now that I understand it.   Thanks!
> 
> You should DEFINITELY include this in the documentation.   Please  :)

Now why order MUST BE such and only such.

* in first I have use this technique in C++.
    later I have to see that Java, REALbasic, C# all have similar abilities
    to get the same technique.

* lets looks on ANY class of REALbasic (for this example).
    we do not talk about V4RB and Valentina now.


* Let we have one or few leaf classes (VFields)

class LeafA

    Constructor()

end

class LeafB

    Constructor()

end


* Now let we have some parent class that must be supervisor of leafs

class Tree

    properties:
        mi  as integer
        ms  as string
        mf1 as LeafA
        mf2 as LeafB
        
    sub constructor
        // By rules of OO design you MUST init data members of class
        // in the constructor. So we dothis

        mi = 0
        ms = "aaaaa"
        
        mf1 = new LeafA()
        mf2 = new LeafB()
    end
end

So you should create tables in constructor of db
And you should create fields in constructor of table.

So you get correct hierarchy of objects by line

    db = new MyDB


-- 
Best regards,

Ruslan Zasukhin
VP Engineering and New Technology
Paradigma Software, Inc

Valentina - Joining Worlds of Information
http://www.paradigmasoft.com

[I feel the need: the need for speed]