On Tue, 23 Feb 2010, Maurilio Longo wrote:
Hi,
> > We have some initial code used for class declaration and strong typing but
> > it was never fully functional.
> Do we need strong typing to spot undeclared variables?
No, we didn't but it touches exactly the same area.
We do not have to implement both things in compiler in the same time
but we have to agree syntax used prototyping (you have to inform
compiler aboout the class definition if you want to detect wrong/undfined
messages). If we create syntax only for one things then it's big risk
that we will have to remove it in the future adding second one.
> > 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
> >
> What's the need to write
>
> x := str( x as numeric )
>
> given that I'm calling str? It seems to me just a waste of typing,
It's necessary if you want to enable full strict type checking at compile
time using some compiler switch. In such mode compiler should warn during
compilation about all possible type mismatch.
Function STR() is declared as:
FUNC STR( nVal AS NUMERIC, [ <nLen> AS NUMERIC ], [ <nDec> AS NUMERIC ] ) ;
AS CHARACTER
Without explicit casting for code like:
func f( x as usual ) as string
x := str( x )
in strict strong type mode compiler should generate warning:
'conversion from USUAL to NUMERIC type'
and casting is necessary to pacify such warning.
Later such compile time strict typing mode can be extended in few ways,
i.e.:
1. we can add option to generate additional devel code which will generate
error at runtime if given variable has different type. It may help
during application tests.
2. we can add option to generate code optimized for strictly defined
types dropping any runtime type validation, in some cases we can
even automatically switch to native C types. Such places like above
with explicit casting from other or unknown types can be encapsulated
in code which will make runtime conversion to given type or depending
on compiler switches accept user casting without any conversions.
This is the place which still can give us serious performance
improvement in the future.
> even more so given the previous valtype which confirms it is a number.
Hardcoding inside compiler semantic of all RTL functions is in practice
impossible. We can make an exception for VALTYPE() but it does not give
us any reasonable solution for general problem (see above) but it will
address only one particular situation. It also hardly complicates the
compiler internal logic because it introduces pseudo strong variables
which can dynamically change the type and we will have to add support
for such situation. It seems to be more complicated modification then
the whole rest we are talking about. I think that we may add sth like
that in the final state when we create logic for code optimization using
strong type information.
> > 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 )
> I really don't like this solution, .Something. operators are logical for me,
> while this one would be different.
> I'd say, what about
> x:toNumber()
> to treat it like an (implicit) object?
It's also possible though I'd prefer functions. Method does not generate
compile or link time errors when name conflicts appear.
We can also use dot only as type operator and instead of:
x.as.number
we can have:
x.asNumber
or:
x.number
(<exp>).number
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
