0000011: Add #include (or similar)

Notes
(0000001) brad (administrator) 2002-03-18 22:37 edited on: 2002-03-18 23:41	This feature may have limited use without the ability to create locally scoped variables. Name conflicts would be common and difficult to debug. edited on: 03-18-02 23:41

(0000083) sorcerer (reporter) 2002-04-14 15:54 edited on: 2002-04-14 15:55	I don't think name conflicts would be much of a problem. Libraries could simply use something before there names. For example Angle becomes xzxAngle. Also a few simple libaries could be included to deal with simple stuff like the commands Jeep wanted here: http://dev.robotbattle.com/mantis/view_bug_page.php?f_id=0000062 [^] edited on: 04-14-02 15:55

(0000084) JEEP (reporter) 2002-04-15 00:14	Also the problem with re-entering bots only for having a fresh 'secret key' could be deal with #include author.dat

(0000516) jamie (reporter) 2002-12-03 03:52	It's possible to have local variables with the current system of variable properties. I use them in a robot of mine. It works like this: Within my section, I first do gosub(save_local) and just before I return, I do gosub(restore_local). And within the section, all local variables are properties of the variable named "local". So local.x, local.y, local.angle, or whatever. save_local { copy(oldlocal, local) copy(local, 0) copy(local.old, oldlocal) copy(oldlocal, 0) } restore_local { copy(oldlocal, local.old) copy(local, oldlocal) copy(oldlocal, 0) } This effectively creates a stack, or another way to think of it is as a linked list, with the ".old" property being a pointer to the tail of the list. This has the advantage that you don't pollute your global namespace with garbage, which is good in another way: when viewing your robot in the inspector, you don't have thousands and thousands of variables to wade through. Furthermore, if you hit an assert in the middle of code, you can see all local variables in all contexts, i.e. you can see the local variables of the calling routines as well, by expanding the local.old property variables. (you could even call it something cryptic to prevent people from accidentally clobbering the stack with a local variable named 'old'.) So, to summarize, I think an #include feature alone could allow properly written libraries to be used effectively, without polluting the global namespace or introducing variable conflicts. Now whether that will actually happen is another matter...

(0000517) brad (administrator) 2002-12-03 10:30	True local variables, real function calls with parameters and return values, and #include are a few of the top items for the next version. Assuming user feedback doesn't change my opinion.

Issue History
Date Modified	Username	Field	Change

Relationships