Telling tables what their fields are

[Ed Kleban]

On 11/19/05 8:41 AM, "Ruslan Zasukhin" <sunshine at public.kherson.ua> wrote:
  
> 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.
>  

Oh no, I fully intend to use the classes way.  I like the elegance of it
very much.  It's the "hidden" aspect of it that I find unaesthetic.

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

LOL.  Different strokes for different folks!  But making it an optional
parameter that defaults to the behavior it has now would permit both modes
of usage, and more importantly as I note above, make it explicit.

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

Yes, I understand how it works.  As I say it's quite elegant, and I intend
to use it just this way.  You talk about the way "you should" do things,
which reflects your opinions on how people should write code.  And what you
recommend is in keeping with object-oriented principles -- which is great.

I'm simply expressing my opinions that:

1) I prefer a coding style that permits "you can" rather than "you should"
or "you must".

2) That DOES NOT USE GLOBAL VARIABLES TO HIDE MECHANISMS, but rather makes
it explicit, or allows the user to optionally make it explicit, what is
happening.  To do otherwise simply goes against my personal opinions of what
"you should" do when writing code.  Using global variables like this doesn't
rank as high on my list of evil coding practices as prolific use of GOTO
statements.  But it is on my list.

Don't sweat it Ruslan, it's just a difference in design philosophy and
coding styles.  Since you wrote the code, you get to pick the style :)
That's fine.  I'll use it and enjoy it.   Just offering you a counter
opinion of how I might have done it differently and why.