Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
October 2012
- 82 participants
- 1024 messages
Re: [Pharo-project] Yet another Notation format: Object literals
by Igor Stasenko
On 19 October 2012 18:18, Dale Henrichs <dhenrich(a)vmware.com> wrote:
> If you guys are all fired up to write parsers:) writing a YAML parser for Smalltalk would be very cool. There are yaml parsers for a bunch of languages, but a Smalltalk parser is conspicuously absent ...
>
> YAML is very readable (all the extraneous gibberish has been removed from the syntax)... YAML appears to be the format of choice when humans and computers need to share the data file and would be not only work across dialects...
>
Well, you miss the point then.
My point was how we can represent a arbitrary object using smalltalk syntax.
That way, users don't need to learn different syntax to express data
in different way..
And this notation is not limited only for exchanging data via files..
it has own uses in a language itself!
myColors
^ #( Dictionary
yellow (Color 1 1 0)
blue (Color 0 0 1)
red (Color 1 0 0)
) fromObjectLiteral.
please note, that it can be even optimized by Compiler!
You can easily detect that #fromObjectLiteral is sent to an array
literal, so you can perform such conversion at compile time.. which
means that given method, when compiled will already contain such
literal (like dictionary
with colors in the above example) ready for use and no run-time overhead.
> Dale
>
> [1] http://www.yaml.org/
>
> ----- Original Message -----
> | From: "Dale Henrichs" <dhenrich(a)vmware.com>
> | To: Pharo-project(a)lists.gforge.inria.fr
> | Sent: Friday, October 19, 2012 8:56:43 AM
> | Subject: Re: [Pharo-project] Yet another Notation format: Object literals
> |
> | Sven,
> |
> | Everybody needs a help from a parser to get formated input right ...
> | I rely on sytax highlighting when I write Smalltalk code:), but I'd
> | say the lack of key/value syntax is more than "a bit worse" for
> | readability.
> |
> | I don't spend a lot of time reading/writing STON files but when I
> | do...I read more often than write and with syntactic key/value
> | demarcation I can read a dictionary with reasonable certainty and
> | make minor edits with confidence (with or without formatting
> | help)... with an undifferentiated list of key value pairs ... forget
> | it:), especially when there are much more readable alternatives
> | available.
> |
> | Dale
> | ----- Original Message -----
> | | From: "Sven Van Caekenberghe" <sven(a)stfx.eu>
> | | To: Pharo-project(a)lists.gforge.inria.fr
> | | Sent: Friday, October 19, 2012 8:29:07 AM
> | | Subject: Re: [Pharo-project] Yet another Notation format: Object
> | | literals
> | |
> | | Dale,
> | |
> | | We have a web app where users sometimes have to enter some short
> | | pieces of JSON - because we were lazy and did not provide a proper
> | | interface ;-) You wouldn't believe in how many ways they make
> | | syntax errors and don't understand it !
> | |
> | | Alternating key value elements is not that worse than key:value or
> | | key->value IMO, but it is a bit worse, agreed. The advantage is
> | | that
> | | you don't need extra syntax/semantics.
> | |
> | | Also, we could agree on
> | |
> | | #(#Time '15:24:01Z')
> | | #(#Date '2012-10-19')
> | | #(#DateAndTime '2012-10-19T15:24:01Z')
> | |
> | | with dashed and colons being optional.
> | |
> | | Sven
> | |
> | | BTW: Is the # in front of Symbols needed ?
> | |
> | | On 19 Oct 2012, at 16:55, Dale Henrichs <dhenrich(a)vmware.com>
> | | wrote:
> | |
> | | > Igor,
> | | >
> | | > I'm afraid that your notation is not very friendly to humans ...
> | | > a
> | | > computer can keep track of the key value pairs in the literal
> | | > dictionary, but a human will fail very quickly...
> | | >
> | | > The appeal of JSON (and STON) is that the output is readable by
> | | > mere mortals:
> | | >
> | | > (JavaScript Object Notation) is a lightweight
> | | > data-interchange format. It is easy for humans to
> | | > read and write.
> | | >
> | | > What we're missing from Smalltalk is a literal dictionary or
> | | > literal map syntax ... without that I'm afraid that for human
> | | > friendly, lightweight notations we have to step away from the
> | | > Smalltalk syntax - STON does this very nicely BTW...
> | | >
> | | > Dale
> | | >
> | | > ----- Original Message -----
> | | > | From: "Igor Stasenko" <siguctua(a)gmail.com>
> | | > | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr>
> | | > | Sent: Friday, October 19, 2012 4:09:22 AM
> | | > | Subject: [Pharo-project] Yet another Notation format: Object
> | | > | literals
> | | > |
> | | > | 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.
> | | > |
> | | > |
> | | > | --
> | | > | Best regards,
> | | > | Igor Stasenko.
> | | > |
> | | >
> | |
> | |
> | |
> |
>
--
Best regards,
Igor Stasenko.
Oct. 19, 2012
Re: [Pharo-project] Yet another Notation format: Object literals
by Igor Stasenko
On 19 October 2012 18:10, Igor Stasenko <siguctua(a)gmail.com> wrote:
> On 19 October 2012 16:55, Dale Henrichs <dhenrich(a)vmware.com> wrote:
>> Igor,
>>
>> I'm afraid that your notation is not very friendly to humans ... a computer can keep track of the key value pairs in the literal dictionary, but a human will fail very quickly...
>>
>> The appeal of JSON (and STON) is that the output is readable by mere mortals:
>>
>> (JavaScript Object Notation) is a lightweight
>> data-interchange format. It is easy for humans to
>> read and write.
>>
>> What we're missing from Smalltalk is a literal dictionary or literal map syntax ... without that I'm afraid that for human friendly, lightweight notations we have to step away from the Smalltalk syntax - STON does this very nicely BTW...
>
> no problem, Dale.
> What symbol you want to have to separate keys from values?
> is '->' ok?
>
> Dictionary>>asObjectLiteral
>
> "convert a receiver into an object literal "
>
> ^ Array streamContents: [:stream |
> stream nextPut: self class name.
> self keysAndValuesDo: [:key :value |
> stream
> nextPut: key asObjectLiteral;
> nextPut: #->;
> nextPut: value asObjectLiteral ] ]
>
> (Dictionary newFromPairs: #( a b c d)) asObjectLiteral
>
> #(#Dictionary
> #a #'->' #b
> #c #'->' #d)
>
> which if you pretty-print will look like:
>
> #(
> Dictionary
> a -> b
> c -> d
> )
>
> is it better?
and, of course you can even put a delimiter(s):
#(
Dictionary
a -> b.
c -> d.
)
or
#(
Dictionary
a -> b;
c -> d;
)
or:
#(
Dictionary
{ a -> b };
{ c -> d };
)
->> #(#Dictionary #'{' #a #'->' #b #'}' #';' #'{' #c #'->' #d #'}' #';')
this is completely arbitrary... because smalltalk literal syntax is
highly permissive :)
it only a little more work to extract keys and values from already
parsed literal array.
> or you prefer this one:
>
> #(
> Dictionary
> (a -> b)
> (c -> d)
> )
>
> you can do anything you like, by implementing the conversion methods
> in a way you like :)
>
>>
>> Dale
>>
>> ----- Original Message -----
>> | From: "Igor Stasenko" <siguctua(a)gmail.com>
>> | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr>
>> | Sent: Friday, October 19, 2012 4:09:22 AM
>> | Subject: [Pharo-project] Yet another Notation format: Object literals
>> |
>> | 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.
>> |
>> |
>> | --
>> | Best regards,
>> | Igor Stasenko.
>> |
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
--
Best regards,
Igor Stasenko.
Oct. 19, 2012
Re: [Pharo-project] Yet another Notation format: Object literals
by Dale Henrichs
If you guys are all fired up to write parsers:) writing a YAML parser for Smalltalk would be very cool. There are yaml parsers for a bunch of languages, but a Smalltalk parser is conspicuously absent ...
YAML is very readable (all the extraneous gibberish has been removed from the syntax)... YAML appears to be the format of choice when humans and computers need to share the data file and would be not only work across dialects...
Dale
[1] http://www.yaml.org/
----- Original Message -----
| From: "Dale Henrichs" <dhenrich(a)vmware.com>
| To: Pharo-project(a)lists.gforge.inria.fr
| Sent: Friday, October 19, 2012 8:56:43 AM
| Subject: Re: [Pharo-project] Yet another Notation format: Object literals
|
| Sven,
|
| Everybody needs a help from a parser to get formated input right ...
| I rely on sytax highlighting when I write Smalltalk code:), but I'd
| say the lack of key/value syntax is more than "a bit worse" for
| readability.
|
| I don't spend a lot of time reading/writing STON files but when I
| do...I read more often than write and with syntactic key/value
| demarcation I can read a dictionary with reasonable certainty and
| make minor edits with confidence (with or without formatting
| help)... with an undifferentiated list of key value pairs ... forget
| it:), especially when there are much more readable alternatives
| available.
|
| Dale
| ----- Original Message -----
| | From: "Sven Van Caekenberghe" <sven(a)stfx.eu>
| | To: Pharo-project(a)lists.gforge.inria.fr
| | Sent: Friday, October 19, 2012 8:29:07 AM
| | Subject: Re: [Pharo-project] Yet another Notation format: Object
| | literals
| |
| | Dale,
| |
| | We have a web app where users sometimes have to enter some short
| | pieces of JSON - because we were lazy and did not provide a proper
| | interface ;-) You wouldn't believe in how many ways they make
| | syntax errors and don't understand it !
| |
| | Alternating key value elements is not that worse than key:value or
| | key->value IMO, but it is a bit worse, agreed. The advantage is
| | that
| | you don't need extra syntax/semantics.
| |
| | Also, we could agree on
| |
| | #(#Time '15:24:01Z')
| | #(#Date '2012-10-19')
| | #(#DateAndTime '2012-10-19T15:24:01Z')
| |
| | with dashed and colons being optional.
| |
| | Sven
| |
| | BTW: Is the # in front of Symbols needed ?
| |
| | On 19 Oct 2012, at 16:55, Dale Henrichs <dhenrich(a)vmware.com>
| | wrote:
| |
| | > Igor,
| | >
| | > I'm afraid that your notation is not very friendly to humans ...
| | > a
| | > computer can keep track of the key value pairs in the literal
| | > dictionary, but a human will fail very quickly...
| | >
| | > The appeal of JSON (and STON) is that the output is readable by
| | > mere mortals:
| | >
| | > (JavaScript Object Notation) is a lightweight
| | > data-interchange format. It is easy for humans to
| | > read and write.
| | >
| | > What we're missing from Smalltalk is a literal dictionary or
| | > literal map syntax ... without that I'm afraid that for human
| | > friendly, lightweight notations we have to step away from the
| | > Smalltalk syntax - STON does this very nicely BTW...
| | >
| | > Dale
| | >
| | > ----- Original Message -----
| | > | From: "Igor Stasenko" <siguctua(a)gmail.com>
| | > | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr>
| | > | Sent: Friday, October 19, 2012 4:09:22 AM
| | > | Subject: [Pharo-project] Yet another Notation format: Object
| | > | literals
| | > |
| | > | 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.
| | > |
| | > |
| | > | --
| | > | Best regards,
| | > | Igor Stasenko.
| | > |
| | >
| |
| |
| |
|
Oct. 19, 2012
Re: [Pharo-project] Yet another Notation format: Object literals
by Igor Stasenko
On 19 October 2012 16:55, Dale Henrichs <dhenrich(a)vmware.com> wrote:
> Igor,
>
> I'm afraid that your notation is not very friendly to humans ... a computer can keep track of the key value pairs in the literal dictionary, but a human will fail very quickly...
>
> The appeal of JSON (and STON) is that the output is readable by mere mortals:
>
> (JavaScript Object Notation) is a lightweight
> data-interchange format. It is easy for humans to
> read and write.
>
> What we're missing from Smalltalk is a literal dictionary or literal map syntax ... without that I'm afraid that for human friendly, lightweight notations we have to step away from the Smalltalk syntax - STON does this very nicely BTW...
no problem, Dale.
What symbol you want to have to separate keys from values?
is '->' ok?
Dictionary>>asObjectLiteral
"convert a receiver into an object literal "
^ Array streamContents: [:stream |
stream nextPut: self class name.
self keysAndValuesDo: [:key :value |
stream
nextPut: key asObjectLiteral;
nextPut: #->;
nextPut: value asObjectLiteral ] ]
(Dictionary newFromPairs: #( a b c d)) asObjectLiteral
#(#Dictionary
#a #'->' #b
#c #'->' #d)
which if you pretty-print will look like:
#(
Dictionary
a -> b
c -> d
)
is it better?
or you prefer this one:
#(
Dictionary
(a -> b)
(c -> d)
)
you can do anything you like, by implementing the conversion methods
in a way you like :)
>
> Dale
>
> ----- Original Message -----
> | From: "Igor Stasenko" <siguctua(a)gmail.com>
> | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr>
> | Sent: Friday, October 19, 2012 4:09:22 AM
> | Subject: [Pharo-project] Yet another Notation format: Object literals
> |
> | 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.
> |
> |
> | --
> | Best regards,
> | Igor Stasenko.
> |
>
--
Best regards,
Igor Stasenko.
Oct. 19, 2012
Re: [Pharo-project] Hello + postgresql
by Yanni Chiu
On 19/10/12 4:05 AM, roberto.minelli(a)usi.ch wrote:
>
> I already received some answers, but further hints are appreciated.
Just download a Pharo-1.4 one-click, and proceed to install and setup up
dbxtalk (see: http://dbxtalk.smallworks.com.ar/) The dbxtalk stuff has
the option to use the native PostgreSQL driver.
IMHO, further up front investigation is going to be of limited value.
Just dive in, and ask specific questions as you work through it (e.g.
where do I find ...? Is ... supposed to be working, because I did ...,
and it didn't work).
Oct. 19, 2012
Re: [Pharo-project] Yet another Notation format: Object literals
by Stéphane Ducasse
On Oct 19, 2012, at 5:29 PM, Sven Van Caekenberghe wrote:
> Dale,
>
> We have a web app where users sometimes have to enter some short pieces of JSON - because we were lazy and did not provide a proper interface ;-) You wouldn't believe in how many ways they make syntax errors and don't understand it !
>
> Alternating key value elements is not that worse than key:value or key->value IMO, but it is a bit worse, agreed. The advantage is that you don't need extra syntax/semantics.
yes :)
>
> Also, we could agree on
>
> #(#Time '15:24:01Z')
> #(#Date '2012-10-19')
> #(#DateAndTime '2012-10-19T15:24:01Z')
>
> with dashed and colons being optional.
>
> Sven
>
> BTW: Is the # in front of Symbols needed ?
no
>
> On 19 Oct 2012, at 16:55, Dale Henrichs <dhenrich(a)vmware.com> wrote:
>
>> Igor,
>>
>> I'm afraid that your notation is not very friendly to humans ... a computer can keep track of the key value pairs in the literal dictionary, but a human will fail very quickly...
>>
>> The appeal of JSON (and STON) is that the output is readable by mere mortals:
>>
>> (JavaScript Object Notation) is a lightweight
>> data-interchange format. It is easy for humans to
>> read and write.
>>
>> What we're missing from Smalltalk is a literal dictionary or literal map syntax ... without that I'm afraid that for human friendly, lightweight notations we have to step away from the Smalltalk syntax - STON does this very nicely BTW...
>>
>> Dale
>>
>> ----- Original Message -----
>> | From: "Igor Stasenko" <siguctua(a)gmail.com>
>> | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr>
>> | Sent: Friday, October 19, 2012 4:09:22 AM
>> | Subject: [Pharo-project] Yet another Notation format: Object literals
>> |
>> | 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.
>> |
>> |
>> | --
>> | Best regards,
>> | Igor Stasenko.
>> |
>>
>
>
Oct. 19, 2012
Re: [Pharo-project] Yet another Notation format: Object literals
by Igor Stasenko
On 19 October 2012 17:29, Sven Van Caekenberghe <sven(a)stfx.eu> wrote:
> Dale,
>
> We have a web app where users sometimes have to enter some short pieces of JSON - because we were lazy and did not provide a proper interface ;-) You wouldn't believe in how many ways they make syntax errors and don't understand it !
>
> Alternating key value elements is not that worse than key:value or key->value IMO, but it is a bit worse, agreed. The advantage is that you don't need extra syntax/semantics.
>
> Also, we could agree on
>
> #(#Time '15:24:01Z')
and if you care about human-friendly stuff,
who needs quotes?
#(Time 15:24:01 GMT)
is valid smalltalk syntax:
#(#Time 15 #':' 24 #':' 1 #GMT)
you only need to provide a conversion which is clever enough to
convert this literal into proper instance of Time :)
> #(#Date '2012-10-19')
> #(#DateAndTime '2012-10-19T15:24:01Z')
>
> with dashed and colons being optional.
>
> Sven
>
> BTW: Is the # in front of Symbols needed ?
>
> On 19 Oct 2012, at 16:55, Dale Henrichs <dhenrich(a)vmware.com> wrote:
>
>> Igor,
>>
>> I'm afraid that your notation is not very friendly to humans ... a computer can keep track of the key value pairs in the literal dictionary, but a human will fail very quickly...
>>
>> The appeal of JSON (and STON) is that the output is readable by mere mortals:
>>
>> (JavaScript Object Notation) is a lightweight
>> data-interchange format. It is easy for humans to
>> read and write.
>>
>> What we're missing from Smalltalk is a literal dictionary or literal map syntax ... without that I'm afraid that for human friendly, lightweight notations we have to step away from the Smalltalk syntax - STON does this very nicely BTW...
>>
>> Dale
>>
>> ----- Original Message -----
>> | From: "Igor Stasenko" <siguctua(a)gmail.com>
>> | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr>
>> | Sent: Friday, October 19, 2012 4:09:22 AM
>> | Subject: [Pharo-project] Yet another Notation format: Object literals
>> |
>> | 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.
>> |
>> |
>> | --
>> | Best regards,
>> | Igor Stasenko.
>> |
>>
>
>
--
Best regards,
Igor Stasenko.
Oct. 19, 2012
Re: [Pharo-project] Yet another Notation format: Object literals
by Dale Henrichs
Sven,
Everybody needs a help from a parser to get formated input right ... I rely on sytax highlighting when I write Smalltalk code:), but I'd say the lack of key/value syntax is more than "a bit worse" for readability.
I don't spend a lot of time reading/writing STON files but when I do...I read more often than write and with syntactic key/value demarcation I can read a dictionary with reasonable certainty and make minor edits with confidence (with or without formatting help)... with an undifferentiated list of key value pairs ... forget it:), especially when there are much more readable alternatives available.
Dale
----- Original Message -----
| From: "Sven Van Caekenberghe" <sven(a)stfx.eu>
| To: Pharo-project(a)lists.gforge.inria.fr
| Sent: Friday, October 19, 2012 8:29:07 AM
| Subject: Re: [Pharo-project] Yet another Notation format: Object literals
|
| Dale,
|
| We have a web app where users sometimes have to enter some short
| pieces of JSON - because we were lazy and did not provide a proper
| interface ;-) You wouldn't believe in how many ways they make
| syntax errors and don't understand it !
|
| Alternating key value elements is not that worse than key:value or
| key->value IMO, but it is a bit worse, agreed. The advantage is that
| you don't need extra syntax/semantics.
|
| Also, we could agree on
|
| #(#Time '15:24:01Z')
| #(#Date '2012-10-19')
| #(#DateAndTime '2012-10-19T15:24:01Z')
|
| with dashed and colons being optional.
|
| Sven
|
| BTW: Is the # in front of Symbols needed ?
|
| On 19 Oct 2012, at 16:55, Dale Henrichs <dhenrich(a)vmware.com> wrote:
|
| > Igor,
| >
| > I'm afraid that your notation is not very friendly to humans ... a
| > computer can keep track of the key value pairs in the literal
| > dictionary, but a human will fail very quickly...
| >
| > The appeal of JSON (and STON) is that the output is readable by
| > mere mortals:
| >
| > (JavaScript Object Notation) is a lightweight
| > data-interchange format. It is easy for humans to
| > read and write.
| >
| > What we're missing from Smalltalk is a literal dictionary or
| > literal map syntax ... without that I'm afraid that for human
| > friendly, lightweight notations we have to step away from the
| > Smalltalk syntax - STON does this very nicely BTW...
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "Igor Stasenko" <siguctua(a)gmail.com>
| > | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr>
| > | Sent: Friday, October 19, 2012 4:09:22 AM
| > | Subject: [Pharo-project] Yet another Notation format: Object
| > | literals
| > |
| > | 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.
| > |
| > |
| > | --
| > | Best regards,
| > | Igor Stasenko.
| > |
| >
|
|
|
Oct. 19, 2012
Re: [Pharo-project] Yet another Notation format: Object literals
by Frank Shearar
On 19 October 2012 16:29, Sven Van Caekenberghe <sven(a)stfx.eu> wrote:
> Dale,
>
> We have a web app where users sometimes have to enter some short pieces of JSON - because we were lazy and did not provide a proper interface ;-) You wouldn't believe in how many ways they make syntax errors and don't understand it !
>
> Alternating key value elements is not that worse than key:value or key->value IMO, but it is a bit worse, agreed. The advantage is that you don't need extra syntax/semantics.
>
> Also, we could agree on
>
> #(#Time '15:24:01Z')
> #(#Date '2012-10-19')
> #(#DateAndTime '2012-10-19T15:24:01Z')
>
> with dashed and colons being optional.
>
> Sven
>
> BTW: Is the # in front of Symbols needed ?
No: #(#foo #bar) = #(foo bar) (but it might be a bit of a hack that they are).
frank
> On 19 Oct 2012, at 16:55, Dale Henrichs <dhenrich(a)vmware.com> wrote:
>
>> Igor,
>>
>> I'm afraid that your notation is not very friendly to humans ... a computer can keep track of the key value pairs in the literal dictionary, but a human will fail very quickly...
>>
>> The appeal of JSON (and STON) is that the output is readable by mere mortals:
>>
>> (JavaScript Object Notation) is a lightweight
>> data-interchange format. It is easy for humans to
>> read and write.
>>
>> What we're missing from Smalltalk is a literal dictionary or literal map syntax ... without that I'm afraid that for human friendly, lightweight notations we have to step away from the Smalltalk syntax - STON does this very nicely BTW...
>>
>> Dale
>>
>> ----- Original Message -----
>> | From: "Igor Stasenko" <siguctua(a)gmail.com>
>> | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr>
>> | Sent: Friday, October 19, 2012 4:09:22 AM
>> | Subject: [Pharo-project] Yet another Notation format: Object literals
>> |
>> | 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.
>> |
>> |
>> | --
>> | Best regards,
>> | Igor Stasenko.
>> |
>>
>
>
Oct. 19, 2012
Re: [Pharo-project] Yet another Notation format: Object literals
by Igor Stasenko
On 19 October 2012 17:29, Sven Van Caekenberghe <sven(a)stfx.eu> wrote:
> Dale,
>
> We have a web app where users sometimes have to enter some short pieces of JSON - because we were lazy and did not provide a proper interface ;-) You wouldn't believe in how many ways they make syntax errors and don't understand it !
>
> Alternating key value elements is not that worse than key:value or key->value IMO, but it is a bit worse, agreed. The advantage is that you don't need extra syntax/semantics.
>
> Also, we could agree on
>
> #(#Time '15:24:01Z')
> #(#Date '2012-10-19')
> #(#DateAndTime '2012-10-19T15:24:01Z')
>
> with dashed and colons being optional.
>
> Sven
>
> BTW: Is the # in front of Symbols needed ?
>
good question.. strict syntax, probably yes..
but array literals allow you to omit it i.e.:
#( ( foo ) ) == #( #( #foo) )
--
Best regards,
Igor Stasenko.
Oct. 19, 2012