When I have needed something similar, I have used a pair of lists instead of a pair of atoms.
Then: look up names in the name list, and extract values from the value list. This scales rather nicely, when I need to work with multiple "things". It also extends fairly directly when I need additional information associated with the names. I guess, though, that it's all about how you think about problems. One thing for certain though: whatever you choose, it'll never be perfect (except in a tautological sense -- if you define perfect as what you have). Thanks, -- Raul On Fri, May 1, 2015 at 8:33 AM, Jon Hough <[email protected]> wrote: > You are right, I was being sloppy with nomenclature. > > As for why, it is really to do with communicating with other apps, amd > languages. I think I mentioned a few months ago I was working on an > implementation of msgpack for J, just for fun. Well, to implement it I think > some sort of dictionary object is unavoidable. I tried using boxed pairs to > represent dictionaries but that was insanity squared, since there is way too > much ambiguity between lists of 2 items and a key value pair. > My hashmap implementation actually works pretty well and I can deserialize / > serialize msgpack with very few bugs (it is still a work in progress), but > the ambiguity between boxed literals and objects is scaring me a little. > > --- Original Message --- > > From: "Raul Miller" <[email protected]> > Sent: May 1, 2015 9:21 PM > To: "Programming forum" <[email protected]> > Subject: Re: [Jprogramming] Datatype of an Object > > I think you need to be really careful here: > > Part 1: > > Objects are not values. > > Object references are values. > > So, already, your dictionary cannot contain a dictionary - it can only > contain a reference to a dictionary. > > Part 2: > > "But if it does contain such a value, it becomes necessary to be able > to differentiate it from just an ordinary boxed literal." > > What is that need? > > I mean, I get it - you're trying to emulate something from some other > language. But at the same time, I don't get it - that way lies madness > (though it can be a good exercise to work through). > > I mean, ok, maybe - like you suggest - there isn't a point to all this. > > But if you need to have (<'10') be a dictionary reference in one > context and also need to have (<'10') be something else in some other > context then you are going to need to have some way of determining > which context is relevant. And that means either not letting their > data bleed through into the other context or that means having > information which identifies the context. > > That said, if you want a worked solution, you might be interested in > something like JD? > > Thanks, > > -- > Raul > > > On Fri, May 1, 2015 at 8:04 AM, Jon Hough <[email protected]> wrote: >> The problem is, I am working on a J hashmap/dictionary implementation. And >> there seems little point if the hashmap can not contain another hashmap as a >> value. But if it does contain such a value, it becomes necessary to be able >> to differentiate it from just an ordinary boxed literal. >> Using a GetType style of verb is a partial solution, but I wonder if I just >> so happen to add a key value pair to my dictionary where the value is a >> boxed literal that happens to have exactly the same look as another >> dictionary object I have lying around. This could screw a lot of things up, >> because GetType would and could interpret this value as the object, even >> though it has nothing to do with it. This could actually screw everything >> up. Anyway, it's the solution I'm using until I can find something better. >> One workaround I am thinking of as I type (may not make sense), is to add >> all created dictionaries to an array somewhere and reference everything from >> that array. Then, somehow, if I add a key/value pair to my parent >> Dictionary, where the value is another dictionary, the actual value to store >> could be an index of the array, instead of the actual dictionary object. >> >> Regards,Jon >> >>> From: [email protected] >>> Date: Fri, 1 May 2015 07:43:40 -0400 >>> To: [email protected] >>> Subject: Re: [Jprogramming] Datatype of an Object >>> >>> The other way is to structure your data so you know what you are working >>> with. >>> >>> For example, maintain a parallel structure with the "type information" >>> that you want to be tracking here. >>> >>> Thanks, >>> >>> -- >>> Raul >>> >>> On Fri, May 1, 2015 at 1:26 AM, Jon Hough <[email protected]> wrote: >>> > This seems to be the easiest solution: >>> > >>> > >>> > GetType =: 3 : 0 >>> > >>> > >>> > >>> > try. >>> > >>> > >>> > >>> > 0{ 18!:2 y >>> > >>> > >>> > >>> > catch. datatype y end. >>> > >>> > ) >>> > >>> > >>> > >>> > >>> > I don't like the idea of relying on an error to branch the output, but I >>> > don't know any other way and this seems to output exactly what I need. >>> > Thanks all. >>> > >>> >> Date: Fri, 1 May 2015 10:18:38 +0800 >>> >> From: [email protected] >>> >> To: [email protected] >>> >> Subject: Re: [Jprogramming] Datatype of an Object >>> >> >>> >> use 18!:0 to test for locale name. eg. >>> >> 18!:0 <'foo' >>> >> >>> >> Пт, 01 май 2015, Jon Hough написал(а): >>> >> > Thanks, >>> >> > It seems 18!:2 is more or less what I need. >>> >> > However, it gives an error for Boxed literals. I think I will need >>> >> > to wrap my verb in a try catch and if itcatches an error I know I am >>> >> > dealing with a standard J type. >>> >> > >>> >> > You may be wondering why I would get myself intoa situation where I >>> >> > mistake a boxed literal for an object, but I am creating data >>> >> > structures thatare arrays of both Objects and standard J types. So I >>> >> > need to inspect each item in the structureto see if it is a boxed >>> >> > variable or an object. >>> >> > >>> >> > > Date: Thu, 30 Apr 2015 21:06:01 -0400 >>> >> > > From: [email protected] >>> >> > > To: [email protected] >>> >> > > Subject: Re: [Jprogramming] Datatype of an Object >>> >> > > >>> >> > > You could look at the path of the object, with >>> >> > > >>> >> > > 18!:2 Obj >>> >> > > >>> >> > > Since the path is under the control of the user, you would have to >>> >> > > know >>> >> > > what you do with the path to be able to make sense of it. Often, the >>> >> > > first atom in the path would tell you what you are looking for. >>> >> > > >>> >> > > >>> >> > > >>> >> > > An object (called a 'numbered locale' in the J docs) is not a boxed >>> >> > > integer: it's a boxed string that contains all numberics. You could >>> >> > > check for that with >>> >> > > >>> >> > > isnumloc =: *./@:e.&'0123456789'@> >>> >> > > >>> >> > > Henry Rich >>> >> > > >>> >> > > (Note that it is an error for the first character of a numbered >>> >> > > locale >>> >> > > to be '0'). >>> >> > > >>> >> > > >>> >> > > On 4/30/2015 8:57 PM, Jon Hough wrote: >>> >> > > > It seems of I have an Object,e.g.Obj =: conew 'MyClass' >>> >> > > > And later I want to get the type of Obj >>> >> > > > datatype Obj >>> >> > > > this returns "boxed", which is technically correct, but it seems >>> >> > > > datatype lacks the introspection to look beneath the box at the >>> >> > > > object. >>> >> > > > So is there a way to get the type (i.e. class name if possible) of >>> >> > > > an object? >>> >> > > > e.g. I have some variable Q (which happens to be an instance of >>> >> > > > MyClass).Is there a way to create a verb, getTypeOf, such that >>> >> > > > getTypeOf Q >>> >> > > > returns 'MyClass' >>> >> > > > I couldn't find anything in JForC on this. At the moment I am >>> >> > > > finding it difficult to differentiate boxedintegers from objects. >>> >> > > > ---------------------------------------------------------------------- >>> >> > > > 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 >>> >> >>> >> -- >>> >> regards, >>> >> ==================================================== >>> >> GPG key 1024D/4434BAB3 2008-08-24 >>> >> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 >>> >> gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 >>> >> ---------------------------------------------------------------------- >>> >> 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
