ENUMS simulations // Interface glitches.

[Ruslan Zasukhin]

On 6/19/04 12:11 AM, "Charles Yeomans" <yeomans at desuetude.com> wrote:

>> Btw, let's discuss the next idea.
>> 
>> Right now module Valentina have mixture of constants from different
>> types and enums.
>> 
>> It looks that I can improve this in the next way,
>> And get syntax 100% the same as Java have
>> 
>> * I can create in plugin MANY modules with e.g. name
>> 
>>     ELockType
>> 
>> And constants
>> 
>>     kNoLock, kRadOnly, kReadWrite
>> 
>> 
>> * then we can write such syntax:
>> 
>>     db.SqlSelect(
>>         query,
>>         ECursorType.kServerSide
>>         ELockType.kReadOnly,
>>         Edirection.ForwardOnly )
>> 
>> 
>> Compare to current attempt
>> 
>>     db.SqlSelect(
>>         query,
>>         Valentina.kServerSide
>>         Valentina.kReadOnly,
>>         Valentina.ForwardOnly )
>> 
>> It looks to me that the first way is more clean.
>> And again, Java work with enums in this way.
>> 
> 
> As I understand it, the advantage of enumerations is that one can
> check types at compile time.

Absolutely right, Charles. Even more!

Value of variable of enum type in DEBUGGER must be shown as constant

        v       kServerSide

Right now REALbasic do not have enums, so we need define all variables as
integer. And in RB debugger we see

        v       2       << not many sense, yes? :-)


> I don't see that the scheme you propose
> offers any advantage over Valentina.kCursorServerSide.

Only for developer eye. And I have hope that WHEN REAL implement enums, they
can implement it in exactly this way. So our sources, Charles will not
require changes when this come e.g. In REALbasic 6.0.

Using Valentina.constant syntax, we EXACTLY will go into trap when REAL will
add enums, you see? It is not fatal of course. Just mater of find/replace.


> An alternative here would be to define a query class that has properties like
> ServerSide as Boolean; indeed, I use such a class myself.  But, no matter how
> much you twist and turn, there doesn't seem to be a way to work around the
> lack of enumerations for properties that aren't Boolean in a way that provides
> compile-time checking.  Clearly, one can check assignment at runtime and (as I
> like to do :) raise an exception for invalid values.

Problem still can be with the same values.

Yes, Charles, I also have told many many times,
And I will repeat and repeat this yet many many times,
    even if I will ruddy on RB lists
    and even if REAL team will do not like this.
    I hope that RB community will also add votes to this.

So, REALbasic __Langugae__ still have 2 great holes:

    * enums
    * interfaces. 

I think I must not explain to REAL what is enums. They know this perfectly
from C++ and CodeWarrior.

We already have agree with REAL that Interfaces should support  PROPERTIES,
Like this do COM, CORBA's idl and Visual BASIC. Then if open some variable
of Interface type in the debugger we will see its properties instead of
NOTHING as now. 

Another problem with 'Interfaces' in RB 5.5 -- THEY SIMPLY DO NOT WORK as
promised. Even as promised in RB 5.5. Not works because Bugs.

Paradigma Software have decide DO NOT use interfaces in Valentina for RB
2.0, because it not works as we need it. :-(

     Very pity. Because I was going introduce so many interesting ideas
     based on interfaces.

Let's hope that in RB 6.0 REAL will pay more attention to this FUNDAMENTAL
issues of language. I underline, we talk about LANGUAGE, not about GUI
features or other "interesting" features. IMHO language should be highest
priority. Geoff, what you think?


-- 
Best regards,
Ruslan Zasukhin      [ I feel the need...the need for speed ]
-------------------------------------------------------------
e-mail: ruslan at paradigmasoft.com
web: http://www.paradigmasoft.com

To subscribe to the Valentina mail list go to:
http://lists.macserve.net/mailman/listinfo/valentina
-------------------------------------------------------------