Back from paris ... Eliot I will implement your proposal I like it.
Stef
On Sun, Jul 2, 2017 at 3:33 PM, Stephane Ducasse
<stepharo.s...@gmail.com> wrote:
> 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 <eliot.mira...@gmail.com> wrote:
>> Hi Norbert,
>>
>>
>>> On Jul 1, 2017, at 7:36 AM, Norbert Hartl <norb...@hartl.name> wrote:
>>>
>>>
>>>>> Am 30.06.2017 um 21:14 schrieb Stephane Ducasse <stepharo.s...@gmail.com>:
>>>>>
>>>>> 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 <siguc...@gmail.com>
>>>>>> Date: Fri, Oct 19, 2012 at 1:09 PM
>>>>>> Subject: [Pharo-project] Yet another Notation format: Object literals
>>>>>> To: Pharo Development <pharo-proj...@lists.gforge.inria.fr>
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>
>>
