How to achieve encapsulation in J?

Question

I'm not an expert on scope in J, so please correct me if I make a mistake. (That, in fact, is part of the reason for this question.)

What I want to do is create a name that is visible within (but not without) a locale. Note that assigning with =. does not achieve this.

I think this is impossible, but I'd love confirmation from a J expert.

After seeing Eelvex's answer, I feel I have to clarify my question. Here's what I want: I want a name that is global within a locale but invisible outside a locale, even if you know the name and qualify it with the locale suffix, exactly analogous to a private member of a class in OOP.

Let's imagine a J verb called private that makes a name private within a locale.

cocurrent 'foo'
x =: 3
private 'x' NB. x is still visible to all members of _foo_, but cannot be accessed in any way outside of _foo_
bar =: 3 : 'x & *'
cocurrent 'base'

bar_foo_ 14 NB. This works, because bar_foo_ can see x_foo_
x_foo_ NB. value error. We can't see x_foo_ because it's private to the locale.

Answer 1

Edit, (after OP's edit)

No, you can't hide a name. If an entity is visible in a locale, then it is accessible from all locales. AFAIK the only names that are truly private are names defined with =. inside an explicit : definition

Previews answer:

All names are visible within (but not without) their locale. Eg:

  a_l1_ =: 15
  a_l2_ =: 20
  coclass 'l1'
  a
15
  coclass 'l2'
  a
20
  coclass 'base'
  a
|value error: a

Answer 2

Short answer: Yes, it's impossible in current implementations.

Long answer: You probably should think of locales as being the public part of a class or object (though locales can also be used for other purposes, such as stack frames or closures).

If you want hidden information, you might think about putting it in a different process, or on a different machine, rather than in a locale. You could also try obscuring it (for example, using the foreign function interface, or files), but whether this is valid depends on your reasons for hiding the information.

That said, note that accessing arbitrary information in an arbitrary locale is somewhat like using the debugger api or reflection api in another language. You can do it, but if that's not what you want you should probably avoid doing that.

That said, in my opinion, you should ideally eliminate private state, rather than hide it. (And, if that winds up being too slow, you might also consider implementing the relevant speed-critical part of your code in some other language. J is wonderful for exploring architectural alternatives but the current implementations do not include compilers suitable for optimizing arbitrary, highly serial, algorithms. You could consider (13 :) or (f.) to be compilers - but they are not going to replace something like the gcc build tools and they currently are not capable of emitting code that gcc can handle.)

That said, it's also hypothetically possible that a language extension (analogous to 9!:24) could be added, to prevent explicit access to locales from new sentences.