> 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
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.
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.
>>
