Well, at least part of why it's worked fine so far is because anyone who created a package had to go through jsoftware to publish it...
As more people start to share j packages on github, there's a greater chance of running into naming conflicts. (... And also version dependency conflicts.) On Fri, Sep 17, 2021 at 2:21 PM Eric Iverson <[email protected]> wrote: > When I first designed/implemented locales, I fully expected that it would > be revisited at some point along the lines you suggest. But the flat > structure with copath has proven more resilient than expected. > > I look forward to suggestions in this area. But we want to keep it simple. > > A dead simple scheme like prefixes (j for jsoftware) similar to common port > numbers goes a long way in avoiding name conflicts. Not all in theory, but > perhaps enough in practice. > > On Fri, Sep 17, 2021 at 12:02 PM Michal Wallace <[email protected]> > wrote: > > > very glad to hear this! > > > > I think "big footprint" is what I was really getting at. > > > > Looking at my own code, I tend to use these "accessors" a lot more often > in > > explicit code than in tacit. > > I still think there's a good idea there, but I now think it could be > > handled better with a verb-creating library > > than a special thing for names. > > > > I do have another thought about the `::` thing though, which is a > > new/better hierarchical naming convention for locales. > > Right now, importing a module might result in multiple conames being > > defined. (For example, importing my own > > UI library results in a coname being created for each ui widget class, > and > > there's nothing I can do about that.) > > > > I worry that as more people start to create their own modules, we will > run > > into issues with name collisions. > > I would love to be able to have `load 'tangentstorm/j-kvm'` generate > > exactly one top-level namespace, kvm, > > with other things underneath it: kvm::vm for viewmat, kvm::vt for > > terminal codes kvm::ui::edit , kvm::ui::list , and so on for individual > > widgets. > > > > I'm not necessarily trying to "claim' what "::" means, but... it's such > a > > "big footprint" > > syntax, it should be used for something big. > > > > (I'll try to write this and my '..' thing as proposals on github this > > weekend) > > > > > > On Fri, Sep 17, 2021 at 10:46 AM Eric Iverson <[email protected]> > > wrote: > > > > > Michal, > > > > > > Your comment: "what's up with this new `name::` syntax?" > > > stirred up interesting stuff. > > > > > > The change was in a beta, so was intended to promote discussion. > > > > > > Henry's response: "Possession is nine points of the law. :)" > > > did have a smile, was a simple fact, and should absolutely not be taken > > to > > > mean that the discussion is over. Jsoftware has a good track record of > > > backing out of mistakes :) > > > > > > Your comment triggered a serious new look. We (back to that in a > minute) > > > decided that: > > > 1. the change would lose a whole whack of good primitives: a:: A:: > abc:: > > > etc:: > > > 2. self effacing is for esoteric performance and should not have such a > > big > > > footprint > > > > > > The next beta will probably adopt a spelling of name_: for self > effacing. > > > > > > Your message triggered good discussion and time will tell if it boils > > down > > > to a solid proposal. Though I confess to being very leery of more > > mechanism > > > for assignment in tacit. > > > > > > The WE referred to earlier is myself, Chris, Henry, and Bill. This has > > > worked reasonably well since we lost Ken and Roger had less and less > > > involvement. > > > > > > We don't vote, proceed cautiously, and with consensus. > > > > > > The time is overdue for the involvement of more people and more formal > > > mechanisms. We will move in that direction, but cautiously. Probably > the > > > first step will be creating a more appropriate media than the > programming > > > forum for language changes. > > > ---------------------------------------------------------------------- > > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
