Re: Re: Re: [Harbour] Inconsistency in DATA Types

2008-10-14 Thread [EMAIL PROTECTED]
>Why you can't check it as >if hb_IsBlock( oClass:bDraw ) > Eval( oClass:bDraw ) >endif Hi Petr, This is exactly the problem: I have a codeblock, but sometimes I need set it to nil and I can´t due data type protection. So now I´m converting all calls to: oClass:bDraw = {||nil} and always I

Re: Re: [Harbour] Inconsistency in DATA Types

2008-10-14 Thread frank van nuffel
Hi again, - Original Message - From: "Petr Chornyj" <[EMAIL PROTECTED]> To: Sent: Tuesday, October 14, 2008 6:48 PM Subject: Re: Re: [Harbour] Inconsistency in DATA Types [EMAIL PROTECTED] wrote: BTW I can change empty codeblock datas from nil to {||nil} an

Re: Re: [Harbour] Inconsistency in DATA Types

2008-10-14 Thread Petr Chornyj
[EMAIL PROTECTED] wrote: > > > BTW I can change empty codeblock datas from nil to {||nil} and eval it > always, instead check it. > > Why you can't check it as if hb_IsBlock( oClass:bDraw ) Eval( oClass:bDraw ) endif Regards, Petr -- View this message in context: http://www.nabble

Re: Re: [Harbour] Inconsistency in DATA Types

2008-10-14 Thread [EMAIL PROTECTED]
Hi Przemek, >Think about it but base type checking should not be touched. >Otherwise IMO we should remove it at all because it stops to >give expected RT protection and we can keep it as source code >decoration just like in xHarbour. Remove no. This is a nice feature and help me to find some hidd

Re: [Harbour] Inconsistency in DATA Types

2008-10-14 Thread Szakáts Viktor
so I'd prefer sth different what will keep current PP syntax. Even such minor modification resolved the problem. DATA bDraw AS ?CODEBLOCK INIT nil But we can also use sth what will allow to mix types, f.e.: DATA bDraw AS CODEBLOCK | NIL or we can support additionally: AS { [,]}, f.e.: DATA

Re: [Harbour] Inconsistency in DATA Types

2008-10-14 Thread Przemyslaw Czerpak
On Tue, 14 Oct 2008, [EMAIL PROTECTED] wrote: Hi Toninho, > I don´t know if this is an feature or a problem. If I have > DATA bDraw AS CODEBLOCK INIT nil INIT clause is unprotected and allow to assign any value with declared type respecting. > bDraw accept NIL without problem, but I can´t set i

Re: [Harbour] Inconsistency in DATA Types

2008-10-14 Thread Alex Strickland
[EMAIL PROTECTED] wrote: IMHO codeblock types can receive nil to easy checking, like: if !( oClass:bDraw == nil ) Eval( oClass:bDraw ) endif I agree with you, but I also think other "types" of variables should accept NIL as well. Regards Alex

Re: [Harbour] Inconsistency in DATA Types

2008-10-14 Thread frank van nuffel
Hi Toninho, and all to elaborate on this, it might be a good idea to introduce syntax for nullable (nilable) types, just like in C# it would suffice to assert a declaration with type info, followed by a question mark DATA bDraw AS CODEBLOCK? INIT nil Then this var can be set to a CODEBLOCK or