Charles, RB events?

[Charles Yeomans]

On Feb 4, 2004, at 12:27 PM, Ruslan Zasukhin wrote:

> on 2/4/04 5:06 PM, Charles Yeomans at yeomans at desuetude.com wrote:
>
> Hi Charles,
>
>>> Do you have any ideas, what exactly new cool RB 5.5 have that V4RB 
>>> can
>>> use?
>>>
>>> I was going to use in ne RB SDK
>>>
>>> -- default parameters
>>> -- named constants registered from plugins
>>> -- may be some calbacks
>>>
>>>
>>> Also I consider introducing/replacing of
>>>
>>>     VBaseObject ->I_Table or I_BaseObject
>>>     VField      ->I_Field
>>>
>>> I.e. Introducing of true interface classes, like I have in C++.
>>>
>>> Don't know yet what benefit will be, but must be something.
>
> I can add: I think we MUST add support of exceptions in RB DK.
>
>
>> The most likely candidate for a class interface is VField -- but 
>> please
>> don't use those nasty COM naming conventions.
>
> Hmm, we use in c++ Valentina 2.0 always
>
>     get_Name()
>     put_Name()
>
> As for me, not bad.
> This is the only thing from COM that we use.
>
>> Let's see how this might
>> work.  I assume that all VField subclasses have some common
>> functionality; perhaps the Name property and some other things.  So 
>> you
>> define a class interface VField and an abstract class VAbstractField
>> that implements the interface and supplies common code.
>
> Wait.
>
> 1) I cannot use Vfield as name of interface. It is already used in 
> V4RB 1.x
> as name of classs.

Of course you can; as we say here in the US, it is a woman's 
prerogative to change her mind.  Since VField is an abstract class, I 
think that such a change wouldn't break any existing code.

>
> 2) as name of interfaces can and must be used
>     I_Field
>     I_Table
>     I_Database
>     I_Cursor
>
> Then go
>     I_Field -> I_Field_Imp      -> VShort
>                ^^^^^^^^^^^      -> VUshort
>                 VField          -> Vstring
>                                 -> VBLOB
>
>
> 3) Aha, remember how many times people on RB list have told about some
> ABSTRACTION LAYER for database classes.
>
> I think now it is time for ME develop such abstraction level.
> Then other RB developers will be able subclass these interfaces to e.g.
> Oracle, Postgre, ... Dbs, and use single abstraction layer.
>
> Actually this will be some parallel to idea of RB DB API.
> Don't know if we need make war to REAL, then more that REAL can also 
> connect
> their interface to controls.
>
> In the same time, why so many developers have start develop own layer 
> of
> classes?
>
> What you think?

I think that people have different ideas about the interface they need. 
  For example, I have written a DBQuery class that allows me to build 
SQL queries using the Valentina VField and VBaseObject objects.  It can 
also return a VCursor  -- this allows me to raise an exception if it 
fails, instead of having to add code after every cursor creation to 
check for errors.  But I am not so worried about being able to move 
between databases (assuming VServer pricing is reasonable...).


>
>
>> Would this make it possible to add user-defined field types?
>> The main problem I see is that Valentina would need to know how to
>> create new instances of such user-defined field types, for building
>> VCursors.  For this perhaps VDatabase could expose an event in which
>> one could implement a factory method.
>
> Not so simple.
>
> I think we will not work on this task even in C++.
> Here too many problems:
>     how data store in RAM
>     how store them on disk in table
>     how store them in index
>     how to compare them
>

What I think I had in mind was the ability to define new Valentina 
field types in terms of the existing types.

Charles Yeomans