Hi,
2010/2/23 Viktor Szakáts :
> It means we should name it x:__tonumber(), which
> looks a little strange. Plus, it forces using
> OOP syntax in non-OOP code.
Class(y) does this sort of "type wrapper" or "scalar classes". For example:
n := 15
? n:isKindOf( FooBar() ) // returns .F.
This makes
On Fri, 26 Feb 2010, Mindaugas Kavaliauskas wrote:
Hi,
> >In class implementation we are using:
> > _HB_CLASS [,] // new class
> > _HB_MEMBER [ AS ]
> > _HB_MEMBER { [ AS ] }
> >Of course this is also [x]Harbour only extension and it's hidden for
> >users by PP rules in hbclass.ch
Hi,
Przemysław Czerpak wrote:
In class implementation we are using:
_HB_CLASS [,] // new class
_HB_MEMBER [ AS ]
_HB_MEMBER { [ AS ] }
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
abo
On Tue, 23 Feb 2010, Szak�ts Viktor wrote:
Hi,
> But, indeed the question is, that when such new
> casting syntax can have an importance; is it needed?
> F.e. in Python which is a strongly type language,
> there is no casting, just conversion functions.
And this is an answer: It's strongly typ
On Tue, 23 Feb 2010, Szak�ts Viktor wrote:
Hi,
> Or maybe, and if technically possible:
> QOUT( ( NUMERIC ) x )
Anything we will chose has to create single expression for PP or
we create serious problem for using casting in commands. So any
new proposition should pass this basci PP tested:
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 implemen
Hi,
>> 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
>> .AS. are recognized by PP s single expression, i.e.
>>
>> ? x .as. numeric
>>
>> is well preprocessed by PP to:
>>
>> QOUT( x .as. numeric )
>
> Viktor,
>
> Viktor Szakáts wrote:
>>
>> Or maybe, and if technically possible:
>> QOUT( ( NUMERIC ) x )
>>
> Yes, a lot better, even if I still can't grasp the usefulness of such a code
> for a typeless language which would, anyway, print x.
That's a good question. It was too late to start w
Viktor,
Viktor Szakáts wrote:
>
> Or maybe, and if technically possible:
> QOUT( ( NUMERIC ) x )
>
Yes, a lot better, even if I still can't grasp the usefulness of such a code
for a typeless language which would, anyway, print x.
Maurilio.
--
__
| | | |__| Maurilio Longo
|_|_|_|_
Przemyslaw,
Przemysław Czerpak wrote:
> 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?
> The last part is casting and here we probably have the biggest problem.
> Now it's possibl
Viktor Szakáts wrote:
>
> It's rather a question of controlling this feature.
>
> IMO it's no question that we should protect against
> this kind of error, since it's useful for "most" code
> (all code, which doesn't dynamically creates messages
> and doesn't uses ON ERROR tricks to emulate
>> 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
>
Przemysław Czerpak wrote:
>
>> 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
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 " can be used after
> each variable, i.e.:
> LOCAL cVar AS CHARACTER, nVar AS NUMER
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 inst
You're right, this would be an absolutely useful feature.
For me it's actually a show stopper to ever create any
OOP code in Harbour. It's just too easy to mistype something
and only get to know about it by live testing complete code
flow.
Compiler-level solution doesn't seem to be easy though
Viktor,
yes.
Maurilio.
Viktor Szakáts wrote:
> Hi Maurilio,
>
> On 2010 Feb 22, at 09:02, Maurilio Longo wrote:
>
>> Viktor,
>>
>> 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
>> ig
Hi Maurilio,
On 2010 Feb 22, at 09:02, Maurilio Longo wrote:
> Viktor,
>
> 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 c
Viktor,
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.
Best regards.
Maurilio.
Viktor Szakáts wrote:
>>> lot of success.
>> lot of success. One thing that will make our lives easier in 100,000
>> lines
>> of Clipper code is some sort of switch in Harbour / hbmk2 that will warn
>> you
>> if you are using a variable that wasn't declared by LOCAL, PRIV, MEMVAR,
>> etc
>> etc... in a function.
>>
>
> If tou want to d
smu johnson wrote:
>
> Since using Harbour from Clipper 5.2e, we'd have a few minor problems, and
> a
> lot of success. One thing that will make our lives easier in 100,000
> lines
> of Clipper code is some sort of switch in Harbour / hbmk2 that will warn
> you
> if you are using a variable tha
21 matches
Mail list logo
