> > JavaScript doesn't have to deal with this so npm can just ignore the > issue. >
It actually does have to deal with this issue but I'm not sure how it does it On Monday, December 21, 2015 at 5:23:01 AM UTC+13, Stefan Karpinski wrote: > > This seems to be a design based largely on npm. > > The idea of modules (and packages) being unnamed internally is appealing, > largely for the prospect of it being possible to rename packages without > breaking code that uses them although I'm not certain this is realistic. > > I'm not sold on the idea that it makes sense to load multiple versions of > packages. There are some major issues: > > *Generic functions.* What happens when two different versions of a > package both introduce separate generic function that other packages are > supposed to share? One of the most confusing situations I see people > encounter is when they've reloaded some code that defines a type and have a > generic function that dispatches the old version of that type and they try > to call the function on the new version of the type. The dispatch doesn't > work, of course, but it looks like it should. Very confusing. This seems to > be intentionally introducing a far worse form of that. It's possible that a > coherent story can be told about how to deal with this, but without that > story this seems pretty hard to swallow. > > *Shared system libraries.* What do you do when two different versions of > a package want to load different versions of system libraries? In theory > dlopen can do this but in practice it does not work well at all. JavaScript > doesn't have to deal with this so npm can just ignore the issue. > > *Code generation.* Julia is already a bit of a beast when it comes to the > amount of code that is generated. This makes that N times worse, for some > unknown and potentially fairly large N. > > On Sun, Dec 20, 2015 at 10:05 AM, Tom Breloff <t...@breloff.com > <javascript:>> wrote: > >> My reaction is the same as Tim Holy's. While I agree there are aspects >> of Julia's modules which are not perfect, it's not clear at all how your >> package changes the workflow. In fact, I don't understand anything about >> your package. Could you please try to write up the design thoughts behind >> what you are doing, so that we can understand the high level concepts that >> you are attempting? >> >> On Sun, Dec 20, 2015 at 6:24 AM, Tim Holy <tim....@gmail.com >> <javascript:>> wrote: >> >>> After reading your README example, I'm still left wondering how one >>> works with >>> Kip, or how it fixes the problems you're describing. To me it's not at >>> all >>> obvious how your example "illustrates" the statements you make in the >>> prose. >>> You might consider explaining the meaning of the various arguments to >>> @require, what an "index" file is and what its format should be, and >>> exactly >>> what the call to the emit function is supposed to demonstrate. >>> >>> Best, >>> --Tim >>> >>> On Saturday, December 19, 2015 11:26:53 PM Jake Rosoman wrote: >>> > I forgot to actually link to the project < >>> https://github.com/jkroso/Kip.jl> >>> > >>> > On Sunday, December 20, 2015 at 8:25:04 PM UTC+13, Jake Rosoman wrote: >>> > > Julia's module system is the one part of it I feel confident enough >>> to say >>> > > is bad. It can't handle several versions of the same package. Is >>> hard (or >>> > > impossible?) to depend on packages that aren't in the registry and >>> hard to >>> > > add (controversial) things to the registry. I also find it ugly and >>> hard >>> > > to >>> > > use but now I'm getting into opinions so I'll stop. >>> > > >>> > > Kip solves all these problems and works fine alongside Julia's >>> current >>> > > module system so you can try it out now. I hope that eventually we >>> can >>> > > replace Julia's module system if people generally agree that it's >>> worth >>> > > doing. I've created a poll to measure the communities opinion >>> > > <http://tally.tl/3002Y> and you can change your vote at any time so >>> feel >>> > > free to say no now but follow the discussion. >>> >>> >> >
