A Sandbox file object - Safe file operations for Seamless Sharing

small basic needs new file object. not replacement. file great job with… well… files. no, small basic needs special purpose file object. won't commented out of operation "publish" process. file object lets save , load files user of newly imported program, on computer, without security fears. small basic needs sandbox.

jibba jabba commented on topic of "seamless sharing" in recent blog post:

turtle-maze versus hangman - case seamless sharing

he outlines process small basic comments out "file" operations in published code, , gives examples of issues causes. basic logic sound. if remove possibility of reading , writing files on computer, eliminate mischief programs can cause. issue kind of brute force modification code render programs unusable, or cause bugs , compile errors.

i encountered last issue myself game wrote: meteor shower (import code: rjp883-15).  after first published code, realized silly amount of code being commented out, gutting high score system. more code removed ever bother re-enabling. sighed , reworked system , got down 2 comment lines, 1 read , write. proud of myself published code, realize horror 2 days later new import code wouldn’t run. if imported , ran program compile error (variable not initialized). without read, variables value never set , small basic choked. needed go , waste line set variable 0 before read set again allow code compile (import code: rjp883-17).  

jibba jabba proposed interesting solution. giving each of file operations "enable" parameter. when enable set true (by default), operation function normal. if set false, automatically happen when program published, operation still compile , execute before, file operations not function. reads return nothing, not having opened files, , writes never attempt save information @ all. true benefit stability of imported code. because no code commented out, or removed published files there no chance errors. code run before, minus 1 functionality. , changing false values true simple un-commenting in use.

a slick idea.

i have different suggestion though. idea creation of sandbox object.

the sandbox object set of file commands allow saving , reading file in same way file object works. big difference sandbox file itself. sandbox save single file. sandbox file name match name of executable: programname.sbox. location of sandbox file in same folder executable (program.directory). sandbox file size limited small, 50k. other file operations pretend sandbox file didn't exist, preventing rename , other operations turning sandbox file dangerous. because of predictable size , location, sandbox file available online interpreter.

secure, flexible , filling needs of 99% of file operations small basic called perform. importantly , fulfill "seamless sharing" concept such important part of makes small basic great.

what think? jibba jabba or have solution problem? have better idea? time discussion on topic.

hello coding cat,

you (and jibba jabba) introduce valid points topic, intrusive commenting of file objects. sadly, inconvenience hinders programmer reading program , learning.

sharing extremely crucial in learning process because allows programmers expand coding skills exploring different techniques, data structure, algorithms, , how author solved problems. besides writing code, reading code next important process becoming efficient programmer.

seamless sharing seamless learning.

again, thank both. gives me problem think about. if have of value offer, i'll sure post ideas or thoughts in future.

Learning  >  Small Basic