There is (and never has been) a requirement to publish through Jsoftware. I was just pointing out that having a prefix, such as your 3 initials or company name, would avoid many potential name conflicts.
On Fri, Sep 17, 2021 at 2:50 PM Michal Wallace <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
