Re: Reloading a .io file

Steve, do you still have the code for this you were talking about?  I could really use it now.  In fact all I need help with is implementing the part for accepting arguments in the file-as-method.  I tried making files containing code like:

// in file "myBlock.io"
block(a1, a2,
   mySlot := Object clone do( stuff )
)

or

// in file "myMethod.io"
method(a1, a2,
    mySlot := Object clone do( stuff )
)

and then running them like this:

// in a loader script
folderObject := Object clone
folderObject myBlock := doFile("myBlock.io")
folderObject myBlock call(a, b)

or

// in a loader script
folderObject := Object clone
folderObject myMethod := doFile("myMethod.io")
folderObject myMethod(a, b)

but my problem is I still want to be able to create slots in folderObject from within the file script.  (By default it creates them in locals.)  In other words what I really wanted is more like a "do()" but with arguments:

// in file "myMethod.io"
do(a1, a2,
    mySlot := ...
)

I'm not sure how to implement that.  Or is it better just use an explicit self:

// in file "myMethod.io"
method(a1, a2,
    self mySlot := ...
)

OK yeah that wasn't exactly what I thought I wanted, but I just tried it and that might work instead.  It does successfully create a slot on the folderObject when the method is executed.

I realized that won't be tedious to organize code this way after all, because not every one-line method needs to be in a file by itself.  Instead, I'm thinking of folders more as "module" objects, each file in the folder is a method that, when called, defines a proto for a type in that module.  That proto definition within the file can still itself contain many method definitions within it.  You can gain some benefits from this way of organizing code, without having to subdivide your codebase all the way down to individual methods.  You just stop subdividing it at whatever granularity you're comfortable working with.

--- In [email protected], Steve Dekorte <steve@...> wrote:
>
> 
> On 2011-01-26 Wed, at 07:21 PM, dennisf486 wrote:
> > Steve, I'm not clear whether you mean Io objects should *act like* folders & files, or if you meant to literally use file system folders to represent objects.
> 
> The latter.
> 
> > If the latter I find this interesting because I've thought about this myself.  My idea was that folders inside other folders would represent nested objects.  I think if the structure of the files in the project and the structure of the objects in the program, it is a big win.
> 
> I was talking about it for proto definitions, but mapping the object graph to the filesystem for persistence is also interesting to me.
> 
> > I have already implemented a menu system for my game engine-with-Io scripting, that uses Io files in a folder to create the game menus.  The names of folders and files are used for menu commands, subfolders become sub-menus, and when a menu item is selected it executes the Io code.
> 
> Cool. 
> 
> > I had not considered makings individual methods go into files.  What are the ramifications of that?  I can see where it might provide some interesting possibilities, but could you be more specific about your reasoning for it?  I could see it getting tedious to have every method in a separate file, if you had many very small methods.  But I suppose someone could write an editor or IDE that would manage them for you.
> 
> I have some code for it that I need to release. One advantage is that it may significantly reduce unnecessary version control conflicts as version control systems understand the structure of the file system but not the structure of code.
> 
> Steve
>