Wait, wait, wait... First off, let's acknowledge that when we say "object" here, we do not really mean an object in the normal human sense. Instead we are referring to a computational abstraction which we hope in some sense represents something else.
But that computational abstraction is not a noun or a verb, it's an arbitrarily complex thing. In essence, it's a somewhat crippled virtual machine. And that crippling is deliberate. One of the most important concepts of "object oriented theory" is "information hiding". Of course, information cannot really be hidden, so it's a crippled form of information hiding. But the theory is that if we do not understand what we are working with that that somehow makes things better. Needless to say, that theory is itself somewhat lame. And my expression of it here, even more so. But what it comes down to is: an object is not itself, but a thing which represents itself. Needless to say, this can never be fully implemented. If it was, it would no longer be an object. Anyways... In J, we use limited names as object references. Why? Well, let's take a step back - what is the use for objects? In terms of use, objects represent the interface between people. They give us a way of getting things done in the face of incomplete information. They are, in essence, a deliberate mix of partial understanding and partial misunderstanding. They give us a way of freezing the interface between something one person built and something another person built. Of course, nowadays, machines are getting cheap enough that "virtual" machines can often be replaced by "real" machines. But they are also getting fast enough that often "real" machines are overkill and "virtual" machines are good enough. But this happens at all levels of abstraction - it's not just inside J but at the OS level, and in other languages that we need to deal with these kinds of things. Anyways... I think it's a bit much to expect the language to entirely solve these kinds of abstraction issue. At some point the programmer is going to have to admit some kind of understanding and just give in and do something actually useful. Maybe not every day, but occasionally we do have to admit to understanding something. Or at least, that's what I tell myself. In the case of object references, in J, we should probably have enough skill to write a verb that behaves as we want. See also: http://www.codeproject.com/Articles/35789/Understanding-Factory-Method-and-Abstract-Factory http://blogs.msdn.com/b/oldnewthing/archive/2004/05/07/127826.aspx http://www.boost.org/doc/libs/1_55_0/libs/python/doc/tutorial/doc/html/python/exposing.html Thanks, -- Raul On Sun, Mar 2, 2014 at 7:58 AM, Pascal Jasmin <godspiral2...@yahoo.ca>wrote: > > Back to J, I have never felt the need for nested names > > I think there is a simple feature (bug) missing from j > > if db_application_ is an object, you cannot do > > table1__db_base_ much less field1__table1__db_base_ > > you can do: > field1__table1__d [ d. = db_base_ > > less convenient, but you can also do (if table1 is <'3' locale) > > field1_3_db_application_ > > The issue is not being able to mix __ and _y_ calling conventions. > > > > ----- Original Message ----- > From: chris burke <cbu...@jsoftware.com> > To: Programming forum <programm...@jsoftware.com> > Cc: > Sent: Sunday, March 2, 2014 12:38:13 AM > Subject: Re: [Jprogramming] Intro; Learning J Feedback > > Sorry, I got this wrong (which shows how much this comes up). > > You can indeed use nested names in current kdb+, as in: > > q).a.b.c:123 > q).a.b.c > 123 > > What you cannot do is change context to more than one level below root, > e.g. > > this is OK: > q)\d .a > q.a) > > this fails: > q)\d .a.b > '.a.b > > So nested names is not fully supported. > > 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. > > > > > On Sun, Mar 2, 2014 at 12:35 PM, chris burke <cbu...@jsoftware.com> wrote: > > > > Contrast this with the K tree which I think allows names like this: > > > > > > .node1.node2.node3.leaf > > > > No, this is not possible, at least in the current kdb+ system. > > > > > > > > On Sun, Mar 2, 2014 at 12:28 PM, Raul Miller <rauldmil...@gmail.com > >wrote: > > > >> What I mean by that is that locales cannot contain other locales. > >> > >> name_locale_ > >> > >> Contrast this with the K tree which I think allows names like this: > >> > >> .node1.node2.node3.leaf > >> > >> (using the . to separate names rather than _ and working from left to > >> right > >> rather than from right to left). > >> > >> Of course, K sacrifices "OOP" in its focus on speed. So it might not be > so > >> good in an educational context. But I highly respect Arthur Whitney's > >> taste > >> in tradeoffs, and I think they are worth keeping in mind, especially > when > >> offering explanations. > >> > >> In J, you can have names like this_is_an_example (with embedded > >> underlines) > >> and you can reference that in a locale by including a locale suffix: > >> > >> this_is_an_example_base_=: 1 > >> > >> or > >> foo=: <'base' > >> this_is_an_example__foo=: 2 > >> > >> But this is an error: > >> foo=: <'this_is_odd' > >> this_is_an_example__foo=: 3 > >> |ill-formed name: foo > >> > >> Only the last two underlines matter currently, in J, and locale names > >> cannot contain the '_' character. The other optional '_' characters in > >> names are just decoration. > >> > >> Does this make sense? > >> > >> Thanks, > >> > >> -- > >> Raul > >> > >> > >> On Sat, Mar 1, 2014 at 10:58 PM, chris burke <cbu...@jsoftware.com> > >> wrote: > >> > >> > > ... they all exist on the same level > >> > > >> > I am not sure what you mean by this, but J has had locale paths since > >> J4, > >> > for example this enables OOP, e.g. create an object from a class. See > >> > http://www.jsoftware.com/papers/joop.htm > >> > > >> > > >> > On Sat, Mar 1, 2014 at 2:22 PM, Raul Miller <rauldmil...@gmail.com> > >> wrote: > >> > > >> > > Directories are hierarchical - you can have a directory "inside" > >> another > >> > > directory. > >> > > > >> > > There's no way of doing that with locales - they all exist on the > same > >> > > level (though of course you can have a reference to any locale > inside > >> any > >> > > locale). > >> > > > >> > > Thanks, > >> > > > >> > > -- > >> > > Raul > >> > > > >> > > > >> > > > >> > > On Sat, Mar 1, 2014 at 12:25 AM, Don Guinn <dongu...@gmail.com> > >> wrote: > >> > > > >> > > > I don't understand what you mean when you say "locals are not > >> > > > hierarchical". Locales are just name spaces. Locales are > implicitly > >> > > > referenced through path (18!:2). The path determines how locales > are > >> > > > searched to resolve a name not found in the current locale. This > >> search > >> > > is > >> > > > hierarchical. The locales are searched in the order specified in > >> 18!:2. > >> > > But > >> > > > each locale has its own path. In this way the hierarchy of locales > >> > > depends > >> > > > on the current locale. In this way it is easy to implement classes > >> in > >> > J. > >> > > > But paths can be used outside of J classes in interesting ways. > >> > > > > >> > > > > >> > > > On Fri, Feb 28, 2014 at 8:52 PM, Steven Taylor <tayl...@gmail.com > > > >> > > wrote: > >> > > > > >> > > > > the verbname__location / verbname_location_ format places more > >> > emphasis > >> > > > on > >> > > > > the verb or noun inside that locale (assuming a left to right > >> > cultural > >> > > > > reading orientation). That appears illogical because nobody > else > >> > does > >> > > > > that, however it can help with readability if you can get used > to > >> it. > >> > > > > > >> > > > > It also helps if you can flatten out the locale 'tree' (although > >> > > locales > >> > > > > are not hierarchical). I mean just symantically. > >> > > > > > >> > > > > I found the process of re-evaluating how I initially thought > >> > namespaces > >> > > > > 'should' work refreshing and overall I think locales have helped > >> me > >> > > make > >> > > > > better namespace naming choices in other more verbose languages. > >> > > > > > >> > > > > I'd also encourage considering locales outside of a strict oo > >> > context. > >> > > > > Try to stay away from state when possible. > >> > > > > > >> > > > > This is so obvious I am embarrassed that it took me so long to > >> > consider > >> > > > > this -- there are French and english 'locales' in Canada... And > I > >> > > thought > >> > > > > this sense of the word may have been behind J's use of it. > >> Probably > >> > > > that's > >> > > > > obvious to everyone in north America ;-). > >> > > > > > >> > > > > If you find yourself writing > >> > > > > A wrapper just around a structure like this > >> > > > > Dictionary<string,Dictionary<string,obj>>, you'll know that > >> locales > >> > > have > >> > > > > grown on you. I may have done that recently > >> > > > > ;) > >> > > > > > >> > > > > -Steven T. > >> > > > > > >> > > > > > >> > ---------------------------------------------------------------------- > >> > > > > 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 > >> > > > > > ---------------------------------------------------------------------- > 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
