Hi,
> Am 30.06.2017 um 12:03 schrieb Stephane Ducasse <[email protected]>: > > Hi > > recently I started to read a book on machine learning and they > manipulate dictionary of dictionary. (So I started my own > implementation and I will switch to DataFrame). > having an abstract notation for a structure (or dictionary of dictionary) is something really useful. I work a lot with JSON and the creation in pharo is done the same way but you have to call asDictionary all the time which is annoying. This can be rethought and would make things less ugly if we had a good way. If it is close to S-expressions the better. But what is DataFrame? > Now it occurred to me that when we program complex objects we do not > need a compact literal syntax for our objects. But when we manipulate > data objects it is super handy. > > I ended up doing a lot of > > self new > addRow: 'Claudia Puig' > withTaggedValues: > {('Snakes on a Plane' -> 3.5). ('Just My Luck' -> 3.0). > ('The Night Listener' -> 4.5). ('Superman Returns' -> 4.0). ('You, Me > and Dupree' -> 2.5)}. > > And I was not in the mood to write a class for the taggedValues and > writing a class would not have really help me. > > > Now we also have STON but STON is not yet part of the language > grammar. So we have to have an explicit conversion call. > > 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. 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. 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.
