module loading

I think module loading is confusing, especially with Package.path as described here:

http://www.lua.org/manual/5.2/manual.html#6.3

If you agree, I will think of a way to get rid of Package.path .

I agree this is confusing. You can go ahead.

Hugo, before looking at my suggestion, please take the time to fully understand how Lua module loading works.  I plan to throw it all out and replace it with something completely different.

I want all module names to be complete URLs.  This removes ambiguity about how and from where the module is loaded.  But I will allow custom protocols to allow custom module loading.

Out of everything in the Package module, I will only keep Package.require and Package.loaded .  Everything else will be removed.  I will add Package.protocols which will be a map from a URL protocol to a loader function.  The loader function will be passed the URL path and should return either the loaded module or nil if it fails.

I currently have some custom protocols for IO like "java" which is misnamed and should be "classpath".  So the basic protocols would be "file" and "classpath".  To load Java classes, the Java package would add a "class" protocol.  To import ArrayList, you would do:

import "class:java.util.ArrayList"

I would have a standard "luan" protocol defined like this:

function Package.protocols.luan(path)
	return Package.protocols.classpath( "classpath:luan/modules/" .. path )
end

So to import the luan Table module:

import "luan:Table"

The Web_server module could add a "site" protocol like this:

function serve(dir)
	dir = dir.gsub("/$","")  -- remove trailing '/' if any
	function Package.protocols.site(path)
		return Package.protocols.classpath( "file:" .. dir .. path )
	end
	...
end

Then you could do:

import "site:/private/lib/Template"

My approach is more verbose than Lua but I think it is clearer.

I like your suggestion. This is definitely simpler and more intuitive.
I don't see any disadvantages, so you can go ahead with this.

done in rev 265

It looks good.

I ended up adding protocols to Io instead of Package so that one can get an object for any protocol and do IO operations on it.  The method to get the object is Io.get(url) but I am not sure about this name.  The actual resource may not exists, so "get" may not be the right name.  Maybe it should be Io.of(url) .  What do you think is the right name?

I don't follow. Is this the method that is called when we try to import something? If yes, then users won't care about the name of this method because they only see an import statement, not a method call. Please explain.

To read a file

s = Io.get("file:test.txt").read_text()

or

s = Io.protocols.file("test.txt").read_text()

I think "get" is okay. I don't have a strong opinion.

I don't like "get" because I am not getting anything.  Any opinion about these?

s = Io.of("file:test.txt").read_text()

or

s = Io.uri("file:test.txt").read_text()

Io.uri() is fine.

Another idea may be:

s = Io.locate("file:test.txt").read_test()

You can decide.

I renamed it to Io.Uri(), starting upper case because this is like a class.

You can close this.

Closed.

Should I rename Io.protocols.class to Io.protocols.java?

Should I rename Io.protocols to Io.schemes?

no, no.

Please compare URL and URI on Javadoc and Wikipedia and reconsider.

Okay, technically "scheme" is better than "protocol".
Now I also think that "java:" is slightly better than "class:" because "class" is related to object-oriented languages, not necessarily java.

done in rev 273 and jeans rev 121.  You will have to fix your jeans config files.

Everything looks fine.