>From my point of view, locales have basically two uses: (1) building out independent modules (preventing namespace collisions between different people's work, or your own work in different contexts),
(2) education (illustrating concepts) That said, locales support both classes and objects. And in this context, locale paths represent inheritance. Note also that "numbered" locales can be used as objects or as anonymous classes. Locales can also be used to represent (high-level) "stack frames" (without path update) or "dynamic scoping" (with the path representing the stack). Locales can also be used to represent closures. That said, there are costs: (1) The usual time/space costs. (2) You need to tell J when you are done with the locale. Because locales are used to store code being written, and because references are "by name", J cannot assume that you want that code deleted. coerase will schedule the locale to be erased at the next opportune moment (when every current execution context which is using that locale has completed). It's up to you to decide what should happen when a name does not refer to a definition. Many languages adopt the idea that the programmer should not think about these sorts of issues. J takes the opposite approach: you need to think about what you are doing. (Instead, J gives you powerful, high level tools for working with the data.) Thanks, -- Raul On Wed, Mar 12, 2014 at 9:07 AM, Steven Taylor <tayl...@gmail.com> wrote: > I find the concept of locales really useful, and I did neglected to mention > J paths. I think paths are a neat device, however, I have struggled to > find good ways of working with them beyond a scripting "import", or via the > OOP single inheritance "hierarchical" way of using them (a kind of > piecemeal multiple inheritance is not that useful for me). I am keen to > hear about other useful schemes that people have come up with. > > Can I get away with saying that J locales are not hierarchical by default? > ;-) > > Perhaps the J path scheme is too flexible to allow for meta based decorator > pattern. That is, what assumptions could you make about the structures > that you inspect and walk? In most instances, probably there's a simpler > way to go about it. This is in line with Chris' comments: > > "... Back to J, I have never felt the need for nested names, though I > obviously use them in Java and similar languages. Perhaps this is because J > gets by with much shallower locale paths compared to more traditional > languages." > > best, > -Steven > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
