Hi Przemek, (BTW, your msg made me little worried about GTNET :$)
> and this is compatible with some other xbase dialects, i.e. with FlagShip > and AFAIK with VO. > But for variable declaration in [x]Harbour "AS <type>" can be used after > each variable, i.e.: > LOCAL cVar AS CHARACTER, nVar AS NUMERIC, lVar AS LOGICAL > This is incompatible with other xbase dialects which allow to use > "AS <type>" only at the end and it describes type for all vairables > in given declaration, i.e.: > LOCAL nVar1, nVar2, nVar3 AS NUMERIC > In FlagShip and VO declares 3 numeric variables but in [x]Harbour > only nVar3 is declared as numeric variable but nVar1 and nVar2 do > not have strong type, they are AS USUAL. > I do not like this difference and it may cause serious problems > with code portability. > Clipper uses very similar syntax when fields are declared: > FIELD <fieldName, ...> IN <alias> > and "IN <alias>" is used for all fields not only for the last one > so this [x]Harbour extension looks ugly even if compared with only > other Clipper commands. > So I would like to change it and follow other Clipper commands and > xbase dialects. I think I had the opposite opinion back then, but now IMO the FlagShip and VO way looks just fine. > The last part is casting and here we probably have the biggest problem. > Now it's possible to use > <exp> AS <type> > i.e.: > > func f( x as usual ) as string > if valtype( x ) == "N" > x := str( x as numeric ) > elseif valtype( x ) != "C" > x := "" > endif > return x as string > > There is one very bad side effect in such implementation: > It's not compatible with PP, i.e. this code: > > ? x as numeric > > cannot be compiled because PP does not recognize 'x as numeric' > as single expression. For me it discards such syntax and we should > look for sth different. > And here I'm really open for propositions. > The most natural seems to be using pseudo functions like: > > asCharacter( <exp> ) > asNumeric( <exp> ) > asLogical( <exp> ) > > other method is using some new operator which will work well with PP. > I.e. instead of 'AS' we can use '.AS.' because expressions like > <exp> .AS. <type> are recognized by PP s single expression, i.e. > > ? x .as. numeric > > is well preprocessed by PP to: > > QOUT( x .as. numeric ) > > Please think about it. I'd like the function version better, but we'd need hb_ prefix, which makes it look less obvious and more to type. It's also less obvious that this is in fact not a function. So, my preference shift towards '.as.', which is easy to grep, resembles to "AS" keyword, and type keyword can be the exact same as in conjunction with the "AS" keyword. ".as." also makes it better fit into operator overriding scheme. Or maybe, and if technically possible: QOUT( ( NUMERIC ) x ) Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
