hi, I tested require 'foo.bar'

[Tang Daogang]

hi,

 

I find that

 

    local xxx = require 'foo.bar'

 

won't find  foo/bar.lua, but find foo.bar.lua?

 

But write

    local xxx = require 'foo/bar'

is ok.

 

Why do this design?

 

 require 'foo.bar'  package -- subpackage -- module, is it not pretty?

 

this decision with make most lua library unusable....

--
Nothing is impossible.

[Brandon Philips]

On 23:41 Wed 04 Jul 2012, Tang Daogang wrote:
> I find that
>
> local xxx = require 'foo.bar'
>
> won't find foo/bar.lua, but find foo.bar.lua?

Yes, we use the similar pathing to node.js.

> But write
> local xxx = require 'foo/bar'
> is ok.
>
> Why do this design?

The primary reason is that it makes it clear all you are doing is
requiring files. Also it it makes relative and path based imports look
the same.

> require 'foo.bar' package -- subpackage -- module, is it not pretty?
>
> this decision with make most lua library unusable....

That is OK though. Most lua library modules won't play nice as-is on
luvit anyways. They need to be ported to the API that is available on
luvit to be useful and need to be modified to not pollute the globabl
scope in many cases.

luvit uses lua as an implementation language just like node uses
javascript as an implementation language. But, we don't pretend like
everything that runs on the regular lua interpreter will run on luvit.
Just as node doesn't try to emulate all the peculiarities of client side
code.

I hope this helps.

In the spirit of all of the silly acronyms in the node community:

"luvit uses lua but implements require differently" lulbird


Brandon

[Humberto S. N. dos Anjos]

On this (admittedly minor) point, since I've had this discussion on this list already :) :

Wouldn't naming Luvit's import function something else (like, say, import) and removing Lua's standard require (to keep non-Luvit modules from loading) avoid (re-)having this discussion? And also the need for an acronym? Your application will fail faster in case of module mixups (the first module to use require/import wrongly will blow up, instead of looking like it should've worked) and inspection for compatibility is also a lot faster (grep FTW). 

[Tang Daogang]

In fact, we need detailed documents to explain it right now. Document can solve the problem you said.

--
Nothing is impossible.

[Tang Daogang]

hi,

 

I tested:

 

    require 'foo'

 

if I have a directory  modules/foo/init.lua, luvit can load it correctly.

 

luvit support this default rule yet?

--
Nothing is impossible.

[Tim Smart]

Seems like it: https://github.com/luvit/luvit/blob/master/lib/luvit/module.lua#L120

Did it not work or something? If there is a bug then post it on the issue tracker.

Tim.

[Humberto S. N. dos Anjos]

On Wed, Jul 4, 2012 at 10:38 PM, Tang Daogang <daoga...@gmail.com> wrote:

In fact, we need detailed documents to explain it right now. Document can solve the problem you said.

So can search and replace. It's a lot faster, more reliable (for the reasons mentioned earlier), and it's less documentation to Luvit guys to write and us to have to find and read. 

[Tim Caswell]

I will use "require" and it will work the way I want.  This is a core feature of what makes luvit what it is.  I understand this isn't ideal for everyone, but I have very good reasons for wanting this.

Compatibility with the luarocks ecosystem is *not* a priority for luvit.  In fact, not being compatible is a good thing because it makes it less likely someone will pull in libraries that make blocking I/O.

Luvit is *not* lua.  It uses lua in it's technology stack, but it's a new platform.  Porting lua libraries to luvit is pretty easy for this reason, but that's the extent of the compatibility.