> PackObj seems to delegate to HashMap as the only recognized object type? You > are not "digging down" arbitrary objects. Yes, I'm only using hashmaps, because J's types can handle all other MsgPack types. > If the goal is to transfer to and from python, another approach would be some > map to tuple conversion in python (before sending), and tuple to map (after > receiving). That could be automated by using the extended msgPack type (0) is > reserved for map as a tuple structure. My goal is really just to get a working MsgPack implementation in J; the language on the other end should be arbitrary. It's only for fun, but it would be nice if J could implement MsgPack. I haven't yet implemented Ext MsgPack types, that's on the TODO list. Anyway, thanks for your input. I will try to look in-depth at your functional approach.
> Date: Fri, 1 May 2015 20:14:20 +0000 > From: [email protected] > To: [email protected] > Subject: Re: [Jprogramming] Datatype of an Object > > PackObj seems to delegate to HashMap as the only recognized object type? You > are not "digging down" arbitrary objects. > > Perhaps you feel that you need an object for hashmap, because msgPack has its > own entry for it. Its an understandable approach. > > My functional approach can easily be adapted to update an object member > instead of the y input. > > If the goal is to transfer to and from python, another approach would be some > map to tuple conversion in python (before sending), and tuple to map (after > receiving). That could be automated by using the extended msgPack type (0) > is reserved for map as a tuple structure. > > > ----- Original Message ----- > From: Jon Hough <[email protected]> > To: "[email protected]" <[email protected]> > Cc: > Sent: Friday, May 1, 2015 12:50 PM > Subject: Re: [Jprogramming] Datatype of an Object > > >You could instead serialize constructor parameters needed to recreate the > >object, or a dictionary of name/value >pairs. In either case, msgpack's > >extended type would be used with an integer code identifying the object, and > > >what to do when the data is received. > The main issue I'm having is the serialization. When my MsgPack serializer > interrogates the data, to see what the applicaple MsgPack type should be, a > reference to an Object throws a spanner in the works, since it is > indistinguishable from a boxed literal. For now, using s: has cleared up the > problem. > > By the way, if you are interested, my code is here: > https://github.com/jonghough/msgpack-j > It is still buggy and there are bits of code lying in weird places, cus it > needs cleaning up. But, in general it works. > e.g. > S =: '' conew 'HashMap' NB. create new hashmap > > set__S 'key1';3.14159 > > > > > > > set__S 'key2'; 'pi is a number' > > > > > > > set__S 'key3' ; (3 8 12 1) > > > then > packObj s: S NB. used symbol here! If not symbol packObj may do something > stupid. > gives : > > 83a46b657931cb400921f9f01b866ea46b6579339403080c01a46b657932ae70692069732061206e756d626572 > > > NB. insert spaces between bytes. > readable =: insertSpaces > '83a46b657931cb400921f9f01b866ea46b6579339403080c01a46b657932ae70692069732061206e756d626572' > > > NB. added spaces to allow readability with msgpack/json reader: > > > Copy paste readable into http://msgpack-json-editor.com/ > > > and you get > > > { > "key1": 3.14159, > "key3": [ > 3, > 8, > 12, > 1 > ], > "key2": "pi is a number" > } > > > > > which is the correct JSON format of my object S. > > > Also > > > UnS =: unpackObj packObj s: S > > > enumerate__UnS '' > > > should print the key value pairs of UnS, which should be identical to S, > except that any array was turned into a boxed array, for various reasons. > > > > > > Date: Fri, 1 May 2015 16:10:20 +0000 > > From: [email protected] > > To: [email protected] > > Subject: Re: [Jprogramming] Datatype of an Object > > > > Msgpack does follow the philosophy with its extended type which is a pair > > of integer_code, bytedata > > > > the integer_code is user/app defined code that defines wth the bytedata is. > > > > 3!:1 will take any J noun and turn it into a bytestream. You would just > > need an app code to handle dictionaries and other app related structures. > > > > serializing objects in J can be tricky in that locale <'13' in one J > > instance on my computer has no relationship with locale '13' on any other J > > instance in the world. > > > > You could instead serialize constructor parameters needed to recreate the > > object, or a dictionary of name/value pairs. In either case, msgpack's > > extended type would be used with an integer code identifying the object, > > and what to do when the data is received. > > > > > And you didn't see how it was constructed, you would have trouble > > > establishing what datatypes the values are. > > > > This is true for any datastructure. What does the data mean? is a question > > that all code must be aware of. > > > > J does have the power of ducktyping. My dictionary contained only objects. > > Every object can have the noun > > > > wthistherelationshiptothisdict =: ... > > > > defined, and it could be defined if missing by the dictionary handler. A > > dictionary that holds objects of many different types can make much more > > sense than one that holds objects mixed with raw types, though I guess the > > motivator behind everything is an object languages is this issue. > > > > You can do an everything is a box model for J, but if so, you might want to > > avoid object references. > > > > > > ----- Original Message ----- > > From: Jon Hough <[email protected]> > > To: "[email protected]" <[email protected]> > > Cc: > > Sent: Friday, May 1, 2015 11:15 AM > > Subject: Re: [Jprogramming] Datatype of an Object > > > > Hi Pascal, I had a little look through your code (still far from > > understanding it), but it seems, in theory, youcould run into the same > > problems.You add values 18!:3 '' to the Map, but once its in there, it's > > the user's job to remember that that is a locale reference and NOT a boxed > > literal, correct? As I said, I'm far from understanding how you did what > > you did.Your methods are rather more advanced than mine. But, in theory, if > > someone showed you the data structure define by > > > > a =: (2 ;< 18!:3 '') kvset (1 ; < 18!:3 '') kvadd (1 ; < 18!:3 '') kvset '' > > > > > > And you didn't see how it was constructed, you would have trouble > > establishing what datatypes the values are, as far as I can see. > > > > > > I had thought along the same lines about the deserialization not caring > > about the data it passes. For MsgPack, this is not possible. MsgPack has > > well defined types > > Specification: https://github.com/msgpack/msgpack/blob/master/spec.md > > For example, there are 3 Map types, depending on the number of key/value > > pairs are in the map. If I'm deserializing that byte string that defines > > such a Map, I need to actually put it into a Map-like structure. I tried > > with just "Boxed pairs", but it just doesn't work. But even if I don't > > bother defining a Map and leave it for the "implementor" to figure out, I'm > > really just pushing the problem onto the implementor, because he would > > still need to figure out how to represent Map-like data in J consistently > > and unambiguously. > > > > > > > Date: Fri, 1 May 2015 14:35:26 +0000 > > > From: [email protected] > > > To: [email protected] > > > Subject: Re: [Jprogramming] Datatype of an Object > > > > > > for serialization, > > > > > > there is 3!:1 (undo with 3!:2) and 5!:5 (undo with ".) > > > > > > 5!:5 can also "serialize" verb definitions. > > > > > > The only portability issue with 3!:1 is going from 64 bit J, an integer > > > > 2^31, will need to be either coerced to a double (default) or to > > > extendended when going to 32 bit J. A simple way to avoid this is > > > converting all/dangerous integers to extended. > > > > > > The same philosophy that recommends the dictionary to not care what it > > > stores, also recommends the serialization layer to not care what it is > > > passing around. Just that the same data is recreated. Its up to the > > > user (BYOF extra code) to understand what that data is. > > > > > > > > > ----- Original Message ----- > > > From: Jon Hough <[email protected]> > > > To: "[email protected]" <[email protected]> > > > Cc: > > > Sent: Friday, May 1, 2015 10:00 AM > > > Subject: Re: [Jprogramming] Datatype of an Object > > > > > > Thanks Pascal. This approach is completely different to mine. I can't > > > really comment on your verbs without running them through the dissector, > > > which won't happen until tomorrow, unfortunately. But I will have a look. > > > By the way, I agree with your point about it not being the dictionary's > > > responsibility to "know" what it's values are. Which is kind of the > > > problem. If I am trying to serialize a dictionary and the serializer goes > > > through each value and asks "what type are you?", any boxed literal could > > > be lying, if there is an object whose object reference boxed literal > > > looks identical. And if the boxed literal looks like the reference to the > > > actual parent dictionary, then the whole thing blows up. > > > For a language like C# and Java when you don't know what you're looking > > > at, you can at least tryGetType(), or instanceof, or even > > > TryParse(value), which are all really helpful for (de)serializing data. > > > I'm finding my method difficult mainly because there doesn't seem to be a > > > J equivalent. > > > > > > > > > > Date: Fri, 1 May 2015 13:31:13 +0000 > > > > From: [email protected] > > > > To: [email protected] > > > > Subject: Re: [Jprogramming] Datatype of an Object > > > > > > > > Here is a set of functional functions for working with a dictionary. > > > > the y arg is the dictionary, x is what you want to get out or put in. > > > > > > > > As a point of philosophy, it is not up to the dictionary to care what > > > > it stores. The user of the dictionary is expected to manage what is > > > > inside, and the user can greatly simplify such management by imposing > > > > his own restrictions/uniformity for what goes inside a specific > > > > dictionary. > > > > > > > > The dictionary does need to make sure that it behaves consistently with > > > > 0 1 and many items. > > > > > > > > kvgi =: #@:{.@:] _:`]@.> (<@:[ i.~ (0&{@:]))"1 _ > > > > kvgix =: #@:{.@:] _:`]@.> ([ i.~ (0&{@:]))"0 _ > > > > kvgv =: >@:((1&{@:]) {~ <@:[ i.~ (0&{@:]))"1 _ :: empty > > > > kvgk =: >@:((0&{@:]) #~ >@: (+./L:0) @:([ e.~ L:0 (1&{@:])))"0 _ :: > > > > empty > > > > kvlabel =: <@:[ , <@:] > > > > > > > > scalarize =: {.^: ((,1) -: $) > > > > amend_z_ =: 2 : 0 NB. v is n or n{"num > > > > s=. v"_ y > > > > (u (s{y)) (s}) y > > > > : > > > > s=. v"_ y > > > > (x u (s{y)) (s}) y > > > > ) > > > > > > > > kvadd =: 4 : 0 NB. add appends value if some exist for key > > > > if. 0=# y do. kvlabel&>/ x return. end. > > > > i=. ({.x) kvgix y =. (,.`]@.(2=#@$)) y > > > > if. _=i do. y ,."_ 1 x else. ,&(> scalarize }. x) each amend (<1,i) y > > > > end. > > > > ) > > > > kvset =: 4 : 0 NB. set replaces value. empty start ok. > > > > if. 0=# y do. kvlabel&>/ x return. end. > > > > i=. (> {.x) kvgi y =. (,.`]@.(2:=#@$)) y [ d=. (> scalarize }.x) > > > > if. _=i do. if. 0<# d do.y ,."_ 1 x end. else. if. 0<# d do. d"_ each > > > > amend (<1,i) y > > > > else. (i{."1 y) ,"1 (>:i)}."1 y end. end. > > > > ) > > > > > > > > kvadd will append an item to a key, while kvset replaces a key setting > > > > > > > > ] a=. (2 ;< 18!:3 '') kvset (1 ; < 18!:3 '') kvadd (1 ; < 18!:3 '') > > > > kvset '' > > > > +-------+----+ > > > > |1 |2 | > > > > +-------+----+ > > > > |+--+--+|+--+| > > > > ||12|13|||14|| > > > > |+--+--+|+--+| > > > > +-------+----+ > > > > > > > > > > > > > > > > 1 kvgv a > > > > +--+--+ > > > > |12|13| > > > > +--+--+ > > > > > > > > > > > > As a user of a dictionary, I need to manage dealing with potential > > > > lists of objects only if I can cause them by what I put in. I bring my > > > > own function (BYOF should be a thing) to deal with it, and 18!:0 is > > > > probably the best initial screener. > > > > > > > > The big advantage of dealing with dictionaries functionally, is that > > > > you have a simple list of 2 rows of boxes that you can manipulate any > > > > other way you want. Instead of manipulating them with a series of > > > > kvadd/kvset commands, you can parse a structured 0 : 0 noun to set it > > > > up, or filter items (say those that include objects) from a larger > > > > dictionary. > > > > > > > > A dictionary that contains other dictionaries: > > > > > > > > (3 ; < a) kvset a > > > > +-------+----+--------------+ > > > > |1 |2 |3 | > > > > +-------+----+--------------+ > > > > |+--+--+|+--+|+-------+----+| > > > > ||12|13|||14|||1 |2 || > > > > |+--+--+|+--+|+-------+----+| > > > > | | ||+--+--+|+--+|| > > > > | | |||12|13|||14||| > > > > | | ||+--+--+|+--+|| > > > > | | |+-------+----+| > > > > +-------+----+--------------+ > > > > > > > > As a user, a dictionary that can contain more than 3 types of things > > > > would be a mess to handle, and would be advised to store the type of > > > > thing as well as the item if you really wanted to structure your > > > > storage that way. > > > > > > > > But one way to recognize a dictionary in the above is that it is a 2xn > > > > shaped boxed structure. For most applications I can think of, it would > > > > be sensible to not place non-dictionary 2xn boxed structures into "the" > > > > dictionary. But another way to distinguish between matrixes of boxes > > > > (that could have 2 rows) and dictionaries, is to place another boxing > > > > level around them (turning a matrix into a scalar boxed item) , and so > > > > can use boxing level as a distinguisher of item kinds. > > > > > > > > > > > > ----- Original Message ----- > > > > From: Jon Hough <[email protected]> > > > > To: "[email protected]" <[email protected]> > > > > Cc: > > > > Sent: Friday, May 1, 2015 8:04 AM > > > > Subject: Re: [Jprogramming] Datatype of an Object > > > > > > > > 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 > > > > ---------------------------------------------------------------------- > > 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
