On Mon, 22 Feb 2010, Maurilio Longo wrote:
Hi,
> one thing I'd like to have is the ability of the compiler to spot iVars like
> it does variables, I mean unused, not declared and so on, while it now simply
> ignores all of them and you get an error when executing such code.
Detecting unused instance variables can be implemented _only_ for HIDDEN
ones and only if class if fully implemented in single file without any
externally defined methods and/or friend functions so you should not
expect it will ever have similar functionality to detecting unused local
variables. If we decide to add it then it would be necessary to also add
method to mark them as used (just like HB_SYMNBOL_UNUSED() for normal
variables) so programmer can pacify false warnings when hidden instance
variables are accessed only by methods implemented in different compilation
units (files).
Detecting the usage of not declared messages (used for methods and instance
variables) seems to be much more useful feature and we definitely need it.
We have some initial code used for class declaration and strong typing but
it was never fully functional.
I can try to implement it but I would like to fully remove this code
and start with completely new implementation.
Now I'm very busy with my business projects and I do not have time to
work on any bigger Harbour extensions. I should finish it in next three
months and then I can start to work on it.
Meanwhile we can think about syntax extensions which we will need for
class and function prototyping, strong variable declaration and casting.
Please remember that for efficient usage we will have to add to compiler
support for automatic generating of prototype header files and used syntax
should be readable and editable for programmers.
Now for function and class prototyping we are using modified DECLARE
command. As far as I know it's [x]Harbour only extension which does
not exists in other xbase compatible languages. If I'm wrong then
please inform me about other languages using DECLARE for prototyping
with the exact syntax.
For such prototyping FlagShip uses PROTOTYPE command.
In class implementation we are using:
_HB_CLASS <className> [,<classFuncName>] // new class
_HB_MEMBER <messageName> [ AS <type> ]
_HB_MEMBER { [ AS <type> ] <varName,...> }
Of course this is also [x]Harbour only extension and it's hidden for
users by PP rules in hbclass.ch so I think that only few people knows
about such syntax extension.
For strong typing we are using AS <type>.
It's also used by few other xbase compatible languages anyhow [x]Harbour
implementation is not fully compatible.
For FUNCTION/PROCEDURE declaration "AS <type>" can be used after each
parameter to specify parameter type and at the and to specify the
returned type.
[STATIC | INIT | EXIT] FUNCTION <!funcName!> ;
[( [<par1> [AS <type1>]] [, <parN> [AS <typeN>]] )] [AS <type>]
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.
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.
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
