Thanks all for the suggestions. I did another version on the version of igor and I will do another pass on the asObject package and send it to you.
On Sat, Jul 1, 2017 at 8:22 PM, Eliot Miranda <[email protected]> wrote: > Hi Norbert, > > >> On Jul 1, 2017, at 7:36 AM, Norbert Hartl <[email protected]> wrote: >> >> >>>> Am 30.06.2017 um 21:14 schrieb Stephane Ducasse <[email protected]>: >>>> >>>> But what is DataFrame? >>> >>> the new collection done by alesnedr from Lviv. It is really nice but >>> does not solve the problem of the compact syntax. >>> >>>>> >>>>> STON fromString: 'Point[10,20]' >>>>> >>>> Same goes for JSON. >>>> >>>>> We were brainstorming with marcus and we could have a first nice >>>>> extension: >>>>> >>>>> { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. >>>>>>>> 10@20 >>>>> >>>>> Now in addition I think that there is a value in having an object >>>>> literal syntax. >>>>> >>>>> I pasted the old mail of igor on object literals because I like the >>>>> idea since it does not add any change in the parser. >>>>> Do you remember what were the problem raised by this solution (beside >>>>> the fact that it had too many # and the order was like in ston not >>>>> explicit). >>>>> >>>>> I would love to have another pass on the idea of Igor. >>>> >>>> What I don't like about it is that the object literal exposes the internal >>>> implementation of the object. Everything is based on index. So it could >>>> suffer the same problem as fuel. When you don't have the exact same code >>>> the deserialization fails. >>> >>> Indeed this is why >>> { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. >>> could be more robust. >>> We could extend the object literal syntax to use association for non >>> collection. >>> >> I think it is more robust and more explicit. I do not know what are the >> semantics of detecting something as #Point being a class name. Is it then >> forbidden to use symbols with uppercase letters? I think something like >> >> { #x -> 10 . #y -> 20} asObjectOf: #Point >> >> is handling the format with implicit knowledge of type. While the explicit >> version would be >> >> { #Point -> { #x -> 10 . #y -> 20}} asObject >> >> And then nested objects are as easy as >> >> {#PointCollection -> { >> #points -> { {#Point -> { #x -> 10 . #y -> 20} }. >> {#Point -> { #x -> 5 . #y -> 8} } } } asObject > > The -> messages are just noise and add additional processing for nothing. > This is just as effective: > > { #Point. { #x. 10 . #y. 20}} asObject > > {#PointCollection. { #points. { {#Point. { #x. 10 . #y. 20} }. > {#Point. { #x. 5 . #y. 8} } } } asObject > > So an object is a pair of a class name and an array of slot specifier pairs, > and a slot specifier is a pair of a slot band and a value. And of course > that means that many object specs can be literal, which is useful for storing > in pragmas etc: > > #(PointCollection > (points ((Point (x 10 y 20)) > ((Point (x 5 y 8)))) asObject > >> >> would give a PointCollection of two point objects. My future wish would be >> that there is an object literal parser that takes all of the information >> from the format. And then a object literal parser that is aware of slot >> information. Meaning that the type information can be gathered from the >> object class instead having it to write in the format. In the >> PointCollection the slot for points would have the type information #Point >> attached. The format goes then to >> >> { #points -> { >> { #x -> 10 . #y -> 20 }. >> { #x -> 5 . #y -> 8 } } >> >> which would then the equivalent to something like JSON >> >> { "points" : [ >> { "x" : 10, "y" : 20 }, >> { "x" : 5, "y" : 8 } ] } >> >> What I don't know is how to solve the difference between a dictionary and an >> collection of associations. > > That's incidental to the format, internal to the parser. If the parser > chooses to build a dictionary as it parses so be it. The point is that the > output is as you specify; a tree of objects. > > The thing to think about is how to introduce labels so that sub objects can > be shared in the graph, the naïve deepCopy vs deepCopyUsing: issue. > >> >> Norbert >> >> >> >>>> As a dictionary is both, an array of associations and a key-value store, >>>> it works perfectly there. But for other objects I have doubts. Especially >>>> is in a lot of contexts you need to have a mapping of internal state to >>>> external representation. It can be applied afterwards but I'm not sure >>>> that can work all the time. >>> >>> Yes after we should focus on the frequent cases. And may be having a >>> literal syntax for dictionary would be good enough. >>> >>> I will do another version of igor's proposal with associations to see >>> how it feels. >>> >>>> >>>> my 2 cents, >>>> >>>> Norbert >>>> >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Igor Stasenko <[email protected]> >>>>> Date: Fri, Oct 19, 2012 at 1:09 PM >>>>> Subject: [Pharo-project] Yet another Notation format: Object literals >>>>> To: Pharo Development <[email protected]> >>>>> >>>>> >>>>> Hi, >>>>> as i promised before, here the simple smalltalk-based literal format. >>>>> It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to >>>>> have separate parser (a normal smalltalk parser used for that). >>>>> >>>>> The idea is quite simple: >>>>> you can tell any object to represent itself as an 'object literal' , >>>>> for example: >>>>> >>>>> (1@3) asObjectLiteral >>>>> --> #(#Point 1 3) >>>>> >>>>> { 1@2. 3@4. true. false . nil } asObjectLiteral >>>>> >>>>> -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) >>>>> >>>>> (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) >>>>> asObjectLiteral >>>>> -> >>>>> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') >>>>> >>>>> Next thing, you can 'pretty-print' it (kinda): >>>>> >>>>> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral >>>>> >>>>> '#(#Dictionary >>>>> 1 >>>>> (#Array 1 2 3) >>>>> ''foo'' ''bar'')' >>>>> >>>>> >>>>> and sure thing, you can do reverse conversion: >>>>> >>>>> '#(#Dictionary >>>>> 1 >>>>> (#Array 1 2 3) >>>>> ''foo'' ''bar'')' parseAsObjectLiteral >>>>> >>>>> a Dictionary('foo'->'bar' 1->#(1 2 3) ) >>>>> >>>>> Initially, i thought that it could be generic (by implementing default >>>>> Object>>#asObjectLiteral), >>>>> but then after discussing it with others, we decided to leave >>>>> >>>>> Object>>#asObjectLiteral to be a subclass responsibility. >>>>> So, potentially the format allows to represent any object(s) as >>>>> literals, except from circular referencing objects, of course. >>>>> >>>>> The implementation is fairly simple, as you may guess and contains no >>>>> new classes, but just extension methods here and there. >>>>> >>>>> Take it with grain and salt, since it is just a small proof of >>>>> concept. (And if doing it for real it may need some changes etc). >>>>> Since i am far from areas right now, where it can be used, i don't >>>>> want to pursue it further or advocate if this is the right way to do >>>>> things. >>>>> Neither i having a public repository for this project.. >>>>> >>>>> So, if there anyone who willing to pick it up and pursue the idea >>>>> further, please feel free to do so and make a public repository for >>>>> project. >>>> >> >
