Safety first: 3+1 suggestions for thinBASIC

[Petr Schreiber]

After using ThinBASIC for 3 years for professional work, there are few things which I would like to see imlemented one day. I would like to leave it open for discussion for some time, that is why I didn't post this at Support (http://www.thinbasic.com/community/project.php) area.

Optional script pre-parsing
It is very unpleasant to fall into syntax error trap in some less exposed code branch. It would be nice to have syntax checker, which would formally analyse the script without running it. I think it could be done via metadata from thinBasic_LoadSymbolEx for example.

Encapsulation of code units
Some kind of isolated code units has been raised few times here, I think with the dawn of OOP (http://www.thinbasic.com/community/project.php?issueid=440) this comes true step by step :)

Exception handling
Currently, when ThinBASIC and its modules, (especially TBGL) find a serious issue, they raise a RunTimeError dialog, which stops the execution or write ERR variable, which is not realised very often. It would be nice to have a structured exception handling (try/catch/finally), with ability to raise descriptive messages instead of sometimes vague ERR. Structured proposal is posted as attachement here (http://www.thinbasic.com/community/project.php?issueid=221#attachments).

Bonus round: Test driven developement support
My friend Honza from work gave me a book called "Growing Object Oriented Software, Guided by Tests". It describes very interesting approach of designing software in quite unique way - by writing failing tests for features first, and then the actual code. It is approach worth study, as I can see from work it makes sense - code by Honza basically never crashes, which looks like kind of magic (but it is not something esotheric - "just" well thought developement approach).


Petr

[kryton9]

After playing with many OOP based languages. Although the all object oriented languages are very powerful, not having the option to go procedural and oop seems restrictive.
I like the c++ approach of you can program in any style you like, I just don't like the turn back to c style syntax many new c++11 gurus are using.

Function(some parameters here){
your function code here;
}

And they have gone to all lowercase with underscrores between words, OOOOOOh I hate that.
this_to_me_is_tedious = but_they_are_using_this_everywhere_now;

Sorry, I think I got off topic with syntax and not discussion about errors buried in less used code.

Perhaps a unit testing master program should be released with each major release of thinBasic?

[ErosOlmi]

Few surprises:

http://www.thinbasic.com/community/project.php?issueid=440#note2631 (http://www.thinbasic.com/community/project.php?issueid=440#note2631)

[ErosOlmi]

Optional script pre-parsing
It is very unpleasant to fall into syntax error trap in some less exposed code branch. It would be nice to have syntax checker, which would formally analyse the script without running it. I think it could be done via metadata from thinBasic_LoadSymbolEx for example.

It is something I always think when I work on thinBasic! Always. But how to implement?
thinBasic is not compiled and no pCode is generated so there is no real full scan of the source code.
During script start-up a pre-parsing stage is executed but only few things can be checked: logical flow nesting sequence, opening and closing tags, some lexical correctness. I can add some more checking during this phase but the real full checking is something I still have to understand how to do. Using keyword syntax is possible using your approach (passing keyword syntax inside thinBasic_LoadSymbolEx) but this would increase a lot the size of all DLLs




Encapsulation of code units
Some kind of isolated code units has been raised few times here, I think with the dawn of OOP (http://www.thinbasic.com/community/project.php?issueid=440) this comes true step by step :)

Some news here: http://www.thinbasic.com/community/project.php?issueid=440#note2631




Exception handling
Currently, when ThinBASIC and its modules, (especially TBGL) find a serious issue, they raise a RunTimeError dialog, which stops the execution or write ERR variable, which is not realised very often. It would be nice to have a structured exception handling (try/catch/finally), with ability to raise descriptive messages instead of sometimes vague ERR. Structured proposal is posted as attachement here (http://www.thinbasic.com/community/project.php?issueid=221#attachments).

Your suggestion is very clever and mostly doable. It will be one of my next thinBasic big things.




Bonus round: Test driven developement support
My friend Honza from work gave me a book called "Growing Object Oriented Software, Guided by Tests". It describes very interesting approach of designing software in quite unique way - by writing failing tests for features first, and then the actual code. It is approach worth study, as I can see from work it makes sense - code by Honza basically never crashes, which looks like kind of magic (but it is not something esotheric - "just" well thought developement approach).

Great suggestion! I found a PDF version here http://it-ebooks.info/book/1503/
Personally I have to say that I followed this approach in some of my work projects in the past and I had great results in terms of stability. It is a bit longer during the first phase of the project where many programmers have the natural instinct to just write down few projects details and go directly to the code. During the initial phase it seems you are loosing your time. But, to my opinion, the time spent in making failing test at first is much much less than the time and brain neuron and personal credibility you will loose later if you do not follow this approach.

Ciao
Eros

[ErosOlmi]

Something for you: http://www.thinbasic.com/community/project.php?issueid=440#note2644