3

我不是J领域的专家，所以如果我犯了错误，请纠正我。（事实上​​，这是这个问题的部分原因。）

我想要做的是创建一个在（但不是没有）语言环境中可见的名称。请注意，分配 with=.并不能实现这一点。

我认为这是不可能的，但我希望得到 J 专家的确认。

看到Eelvex的回答后，我觉得我必须澄清我的问题。这就是我想要的：我想要一个在语言环境中是全局但在语言环境之外不可见的名称，即使您知道该名称并使用语言环境后缀对其进行限定，这与 OOP 中类的私有成员完全相似。

让我们想象一个名为 J 的动词private，它使名称在语言环境中成为私有。

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.
4

2 回答 2

2

编辑，（在 OP 的编辑之后）

不，你不能隐藏一个名字。如果实体在区域设置中可见，则可以从所有区域设置访问它。AFAIK唯一真正私有的名称是=.在显式:定义中定义的名称

预览答案：

所有名称都在（但不是没有）它们的语言环境中可见。例如：

  a_l1_ =: 15
  a_l2_ =: 20
  coclass 'l1'
  a
15
  coclass 'l2'
  a
20
  coclass 'base'
  a
|value error: a
于 2013-01-19T01:33:38.200 回答
1

简短的回答：是的，在当前的实现中是不可能的。

长答案：您可能应该将语言环境视为类或对象的公共部分（尽管语言环境也可用于其他目的，例如堆栈帧或闭包）。

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.

于 2013-01-21T21:05:05.503 回答