Using the current facilities you can do
cocurrent PREFIX,'widget'
Would that suffice?
Henry Rich
On 9/17/2021 2:49 PM, Michal Wallace 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
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
