Talk:BlitzMax

Glad to see I'm not quite the only one that thinks this is a good idea. Thanks for not fighting on the page style so far... Just a couple things. The Signature: line for methods/functions should probably have a colon to conform to standard labeling usage. Also I've tried to use a cleaner coding style. I notice a lot of BMax source has strange ways of putting spaces around parameters and no spaces after a comma, or a space before a comma. It just looks really wrong to me, makes it harder to read so I'm trying to keep most of the source more standard.

Anyway hopefully we can get some other people to jump in. I think this is our best bet for a good, permanent documentation source. Blueapples 04:50, 7 May 2007 (UTC)

Forgot to mention, if variables in examples or signatures are left to their default values we should probably put :Int in there to be clear. Blueapples 04:51, 7 May 2007 (UTC)

If someone knows how to, please add this to the computer languages bookshelf. Otus 14:27, 13 May 2007 (UTC) Nevermind, figured it out. Otus 15:11, 13 May 2007 (UTC)
 * I was trying to find how to do that, glad you got it. Blueapples 21:52, 6 June 2007 (UTC)

Organization
The page in growing pretty long... The front page should probably only have an introduction to each topic, and then a separate page for deeper discussion. At least the list of modules needs a separate page soon. Otus 10:03, 26 May 2007 (UTC)

Reorganized the modules on a separate page. Also, I renamed the pages for individual modules as they are names inside the mod directory. Something similiar should be done to Arrays.Otus 11:47, 3 June 2007 (UTC)


 * Good thinking, I knew after content was added that the page might get out of hand. Arrays and Control Structures could also easily use their own pages.
 * I wish I had more time to document additional modules. I will get back to it in a couple weeks hopefully. Blueapples 21:43, 6 June 2007 (UTC)

Code Style
For purposes of documentation, I am thinking it might be best to write all samples so they would compile in SuperStrict mode. Otherwise, we may be misleading by committing information that is assumed by the compiler in less strict modes. On the other hand, it will make samples somewhat more verbose which may also be misleading by implying that BMax is difficult to code in. I'm not sure, but I personally never write code that can't compile in SuperStrict and I believe it's easiest tool to help write reliable code. Probably good to promote that style. Blueapples 21:49, 6 June 2007 (UTC)

I agree, except for very simple beginner examples. There I think we should choose simplicity over more advanced code. Otus 17:57, 29 June 2007 (UTC)

Source for examples
Here is a thread with much information that chould be copied/used here. Otus 17:57, 29 June 2007 (UTC)

Modules page revision
I redid the category structure and added some extra information to the Modules page. I also redid all the existing code and documentation for BRL.Map and BRL.LinkedList for testing/examples.

All the code on the book should be entirely SuperStrict compliant, that way anyone using code examples from the book can use whichever strictness mode they want to (SuperStrict down-levels perfectly with non-Strict and Strict, whereas neither non-Strict and Strict - in most cases - will not go up in strictness). Psyced (talk) 05:31, 24 August 2009 (UTC)