Hi all,
I'd like to contribute to the JSON project, but apparently I lack the required access rights. Would it be possible to review this patch, which adds UTF-16 support for JSON strings, with the final goal to introduce it into the repository? :-)
Best,
Christoph
Here is a second small but, as I hope, useful patch.
Name: JSON-ct.41 Author: ct Time: 5 September 2020, 10:04:48.328336 pm UUID: 15667ebd-25e5-2f45-a758-7ab8df09a3e1 Ancestors: JSON-ct.40
Implements #respondsTo: on JsonObject.
Usage: | anObject | anObject := Json readFrom: '{"foo": 42}' readStream. (anObject respondsTo: #foo) ifTrue: [anObject foo] ifFalse: ["fallback code"].
This is especially helpful when using JsonObjects anywhere in the system as polymorphic substitution for other classes.
Have a nice weekend! Best, Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Thiede, Christoph Gesendet: Samstag, 5. September 2020 21:59 Uhr An: Squeak Dev; Tony Garnock-Jones; Niephaus, Fabio Betreff: [squeak-dev] I'd like to contribute to the JSON project
Hi all,
I'd like to contribute to the JSON project, but apparently I lack the required access rights. Would it be possible to review this patch, which adds UTF-16 support for JSON strings, with the final goal to introduce it into the repository? :-)
Name: JSON-ct.40 Author: ct Time: 5 September 2020, 9:48:49.742336 pm UUID: 85bcdb2a-a65e-b14f-90a6-eb6ad8f82eba Ancestors: JSON-tonyg.39
Adds support and tests for UTF16 unicode strings.
Unicode sequences should not be parsed as two separate characters but rather as a single one with 4 bytes. For more information, see https://tools.ietf.org/id/draft-ietf-json-rfc4627bis-09.html#rfc.section.7.
Best,
Christoph
Hi Levente,
would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be great because I depend on this functionality in another project and currently require your JSON fork in my baseline. :-)
Best, Christoph
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Hi Christoph,
On Sun, 8 Nov 2020, Christoph Thiede wrote:
Hi Levente,
would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be great because I depend on this functionality in another project and currently require your JSON fork in my baseline. :-)
I cannot merge it because that would bring back long removed methods, and MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:.
What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should
JsonObject new respondsTo: #foo:
return false? What should the following return?
JsonObject new foo: 1; respondsTo: #foo:
Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.:
JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject'
PseudoObject >> respondsTo: aSymbol
^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol]
(Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true"
Levente
Best, Christoph
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Hi Levente.
Sounds right. If an object can answer to some extra messages via #doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash.
I did not know about #dictionaryClass:. That's a powerful hook.
Best, Marcel Am 09.11.2020 03:07:54 schrieb Levente Uzonyi leves@caesar.elte.hu: Hi Christoph,
On Sun, 8 Nov 2020, Christoph Thiede wrote:
Hi Levente,
would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be great because I depend on this functionality in another project and currently require your JSON fork in my baseline. :-)
I cannot merge it because that would bring back long removed methods, and MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:.
What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should
JsonObject new respondsTo: #foo:
return false? What should the following return?
JsonObject new foo: 1; respondsTo: #foo:
Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.:
JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject'
PseudoObject >> respondsTo: aSymbol
^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol]
(Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true"
Levente
Best, Christoph
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
+1 for answering true for every simple setter selector as an addition for the implementation I proposed earlier. Sorry I forgot the setters!
For the purpose, I like to make much use of JsonObjects instead of first-class object instances in some scenarios, especially at the beginning of a project when it's an easy hack to mock not-yet implemented classes, or when communicating with a RESTful API. Thanks to dynamic forwarding (see JsonObject >> #doesNotUnderstand:), I can use these JsonObjects interchangeably (polymorphically) with first-class object instances. However, it is a common practice to check whether an object responds to a message before actually sending it, i.e. to determine its type or capabilities dynamically, which is done via #respondsTo:. To strengthen the interchangeability of JsonObject with first-class object instances, I'd like to send #respondsTo: to JsonObjects in order to find out whether it "has" a certain property, for instance:
newOrder respondsTo: #deadline "Check whether the order is an order limited-in-time or whether not. newOrder might be a subinstance of the (abstract) class Order, or a JsonObject."
For more context, see also this thread: http://forum.world.st/Should-you-override-doesNotUnderstand-and-respondsTo-t...
So a better implementation of JsonObject >> #respondsTo: might be the following:
respondsTo: aSymbol
^ (super respondsTo: aSymbol) or: [aSymbol isSimpleGetter and: [self includesKey: aSymbol]] or: [aSymbol isSimpleSetter]
Provided that Json does not need to be compatible with older Squeak versions (the simple[GS]etter stuff is quite new). :-)
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 9. November 2020 08:04:20 An: squeak-dev Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project
Hi Levente.
Sounds right. If an object can answer to some extra messages via #doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash.
I did not know about #dictionaryClass:. That's a powerful hook.
Best, Marcel
Am 09.11.2020 03:07:54 schrieb Levente Uzonyi leves@caesar.elte.hu:
Hi Christoph,
On Sun, 8 Nov 2020, Christoph Thiede wrote:
Hi Levente,
would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be great because I depend on this functionality in another project and currently require your JSON fork in my baseline. :-)
I cannot merge it because that would bring back long removed methods, and MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:.
What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should
JsonObject new respondsTo: #foo:
return false? What should the following return?
JsonObject new foo: 1; respondsTo: #foo:
Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.:
JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject'
PseudoObject >> respondsTo: aSymbol
^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol]
(Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true"
Levente
Best, Christoph
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Hi Marcel,
On Mon, 9 Nov 2020, Marcel Taeumel wrote:
Hi Levente. Sounds right. If an object can answer to some extra messages via #doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash.
In that case JsonObject >> #respondsTo: should return true for all unary and one-argument keyword selectors. But I doubt that's what Christoph would like to have.
Levente
I did not know about #dictionaryClass:. That's a powerful hook.
Best, Marcel
Am 09.11.2020 03:07:54 schrieb Levente Uzonyi <leves@caesar.elte.hu>: Hi Christoph, On Sun, 8 Nov 2020, Christoph Thiede wrote: > Hi Levente, > > would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be > great because I depend on this functionality in another project and > currently require your JSON fork in my baseline. :-) I cannot merge it because that would bring back long removed methods, and MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:. What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should JsonObject new respondsTo: #foo: return false? What should the following return? JsonObject new foo: 1; respondsTo: #foo: Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.: JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject' PseudoObject >> respondsTo: aSymbol ^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol] (Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true" Levente > > Best, > Christoph > > > > -- > Sent from: http://forum.world.st/Squeak-Dev-f45488.html
But I doubt that's what Christoph would like to have.
That is right, I was assuming some kind of late-binding prototypical object model.
For instance, a similar model seems to be used for JavaScript objects:
x = {}
{}
x.foo
undefined
x.hasOwnProperty('foo')
false
x.foo = 42
42
x.foo
42
x.hasOwnProperty('foo')
true
However, I see your concerns, Levente ... My proposal would violate the contract "if and only if #respondsTo: returns true, sending the message will not cause a MNU", if there was any contract like. But do we need logical equivalency for such a contract or would simple causality ("if #respondsTo: returns true, then sending the message will not cause a MNU") suffice? Hm ...
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu Gesendet: Montag, 9. November 2020 15:17 Uhr An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project
Hi Marcel,
On Mon, 9 Nov 2020, Marcel Taeumel wrote:
Hi Levente. Sounds right. If an object can answer to some extra messages via #doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash.
In that case JsonObject >> #respondsTo: should return true for all unary and one-argument keyword selectors. But I doubt that's what Christoph would like to have.
Levente
I did not know about #dictionaryClass:. That's a powerful hook.
Best, Marcel
Am 09.11.2020 03:07:54 schrieb Levente Uzonyi <leves@caesar.elte.hu>: Hi Christoph, On Sun, 8 Nov 2020, Christoph Thiede wrote: > Hi Levente, > > would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be > great because I depend on this functionality in another project and > currently require your JSON fork in my baseline. :-) I cannot merge it because that would bring back long removed methods, and MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:. What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should JsonObject new respondsTo: #foo: return false? What should the following return? JsonObject new foo: 1; respondsTo: #foo: Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.: JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject' PseudoObject >> respondsTo: aSymbol ^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol] (Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true" Levente > > Best, > Christoph > > > > -- > Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Smalltalk - Squeak - Dev | Mailing List Archivehttp://forum.world.st/Squeak-Dev-f45488.html forum.world.st Squeak - Dev forum and mailing list archive. The general-purpose Squeak developers list
On Mon, Nov 9, 2020 at 8:29 AM Thiede, Christoph < Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:
But I doubt that's what Christoph would like to have.
That is right, I was assuming some kind of late-binding prototypical object model.
For instance, a similar model seems to be used for JavaScript objects:
x = {}
{}
x.foo
undefined
x.hasOwnProperty('foo')
false
x.foo = 42
42
x.foo
42
x.hasOwnProperty('foo')
true
However, I see your concerns, Levente ... My proposal would violate the contract "if and only if #respondsTo: returns true, sending the message will not cause a MNU", if there was any contract like. But do we need logical equivalency for such a contract or would simple causality ("if #respondsTo: returns true, then sending the message will not cause a MNU") suffice? Hm ...
If the doesNotUnderstand: is not visible externally then who cares? Isn't the contract (o respondsTo: m) ifFalse: [self should: [o m] raise: MessageNotUnderstood]], or respondsTo: not implies MNU ?
Best,
Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu *Gesendet:* Montag, 9. November 2020 15:17 Uhr *An:* The general-purpose Squeak developers list *Betreff:* Re: [squeak-dev] I'd like to contribute to the JSON project
Hi Marcel,
On Mon, 9 Nov 2020, Marcel Taeumel wrote:
Hi Levente. Sounds right. If an object can answer to some extra messages via
#doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash.
In that case JsonObject >> #respondsTo: should return true for all unary and one-argument keyword selectors. But I doubt that's what Christoph would like to have.
Levente
I did not know about #dictionaryClass:. That's a powerful hook.
Best, Marcel
Am 09.11.2020 03:07:54 schrieb Levente Uzonyi <
leves@caesar.elte.hu>:
Hi Christoph, On Sun, 8 Nov 2020, Christoph Thiede wrote: > Hi Levente, > > would you mind to merge JSON-ct.41 (#respondsTo:) as well? This
would be
> great because I depend on this functionality in another project
and
> currently require your JSON fork in my baseline. :-) I cannot merge it because that would bring back long removed
methods, and
MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >>
#respondsTo:.
What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should JsonObject new respondsTo: #foo: return false? What should the following return? JsonObject new foo: 1; respondsTo: #foo: Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.: JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject' PseudoObject >> respondsTo: aSymbol ^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol] (Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true" Levente > > Best, > Christoph > > > > -- > Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Smalltalk - Squeak - Dev | Mailing List Archive http://forum.world.st/Squeak-Dev-f45488.html forum.world.st Squeak - Dev forum and mailing list archive. The general-purpose Squeak developers list
On Sun, Nov 8, 2020 at 11:04 PM Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Levente.
Sounds right. If an object can answer to some extra messages via #doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash.
And canUnderstand: ? Or is that being too picky?
I did not know about #dictionaryClass:. That's a powerful hook.
Best, Marcel
Am 09.11.2020 03:07:54 schrieb Levente Uzonyi leves@caesar.elte.hu: Hi Christoph,
On Sun, 8 Nov 2020, Christoph Thiede wrote:
Hi Levente,
would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be great because I depend on this functionality in another project and currently require your JSON fork in my baseline. :-)
I cannot merge it because that would bring back long removed methods, and MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:.
What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should
JsonObject new respondsTo: #foo:
return false? What should the following return?
JsonObject new foo: 1; respondsTo: #foo:
Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.:
JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject'
PseudoObject >> respondsTo: aSymbol
^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol]
(Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true"
Levente
Best, Christoph
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
And canUnderstand: ? Or is that being too picky?
Ah, right. On the class level, it would be like Levente inferred from my suggestion. I only thought of #respondsTo: to answer "true" only for the simple setter/getters that have keys present in the actual dictionary instance. Hmmm.....
I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?
Best, Marcel Am 09.11.2020 21:08:14 schrieb Eliot Miranda eliot.miranda@gmail.com:
On Sun, Nov 8, 2020 at 11:04 PM Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Hi Levente.
Sounds right. If an object can answer to some extra messages via #doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash.
And canUnderstand: ? Or is that being too picky?
I did not know about #dictionaryClass:. That's a powerful hook.
Best, Marcel Am 09.11.2020 03:07:54 schrieb Levente Uzonyi <leves@caesar.elte.hu [mailto:leves@caesar.elte.hu]>: Hi Christoph,
On Sun, 8 Nov 2020, Christoph Thiede wrote:
Hi Levente,
would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be great because I depend on this functionality in another project and currently require your JSON fork in my baseline. :-)
I cannot merge it because that would bring back long removed methods, and MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:.
What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should
JsonObject new respondsTo: #foo:
return false? What should the following return?
JsonObject new foo: 1; respondsTo: #foo:
Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.:
JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject'
PseudoObject >> respondsTo: aSymbol
^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol]
(Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true"
Levente
Best, Christoph
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html [http://forum.world.st/Squeak-Dev-f45488.html]
--
_,,,^..^,,,_
best, Eliot
Hi all, for importing Matlab struct, I create classes on the fly and generate the getter setter on demand (via doesNotUnderstand:) See MatFileReader package in http://www.squeaksource.com/STEM.html
Le mar. 10 nov. 2020 à 09:06, Marcel Taeumel marcel.taeumel@hpi.de a écrit :
And canUnderstand: ? Or is that being too picky?
Ah, right. On the class level, it would be like Levente inferred from my suggestion. I only thought of #respondsTo: to answer "true" only for the simple setter/getters that have keys present in the actual dictionary instance. Hmmm.....
I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?
Best, Marcel
Am 09.11.2020 21:08:14 schrieb Eliot Miranda eliot.miranda@gmail.com:
On Sun, Nov 8, 2020 at 11:04 PM Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Levente.
Sounds right. If an object can answer to some extra messages via #doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash.
And canUnderstand: ? Or is that being too picky?
I did not know about #dictionaryClass:. That's a powerful hook.
Best, Marcel
Am 09.11.2020 03:07:54 schrieb Levente Uzonyi leves@caesar.elte.hu: Hi Christoph,
On Sun, 8 Nov 2020, Christoph Thiede wrote:
Hi Levente,
would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be great because I depend on this functionality in another project and currently require your JSON fork in my baseline. :-)
I cannot merge it because that would bring back long removed methods, and MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:.
What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should
JsonObject new respondsTo: #foo:
return false? What should the following return?
JsonObject new foo: 1; respondsTo: #foo:
Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.:
JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject'
PseudoObject >> respondsTo: aSymbol
^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol]
(Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true"
Levente
Best, Christoph
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
-- _,,,^..^,,,_ best, Eliot
and generate the getter setter on demand (via doesNotUnderstand:)
That's what I opted for, too, in: https://github.com/hpi-swa/MessageSendRecorder [https://github.com/hpi-swa/MessageSendRecorder%5D%C2%A0%27s MessageSendRecordExtension.
Best. Marcel Am 10.11.2020 09:32:07 schrieb Nicolas Cellier nicolas.cellier.aka.nice@gmail.com: Hi all, for importing Matlab struct, I create classes on the fly and generate the getter setter on demand (via doesNotUnderstand:)
See MatFileReader package in http://www.squeaksource.com/STEM.html [http://www.squeaksource.com/STEM.html]
Le mar. 10 nov. 2020 à 09:06, Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> a écrit :
And canUnderstand: ? Or is that being too picky?
Ah, right. On the class level, it would be like Levente inferred from my suggestion. I only thought of #respondsTo: to answer "true" only for the simple setter/getters that have keys present in the actual dictionary instance. Hmmm.....
I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?
Best, Marcel Am 09.11.2020 21:08:14 schrieb Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]>:
On Sun, Nov 8, 2020 at 11:04 PM Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Hi Levente.
Sounds right. If an object can answer to some extra messages via #doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash.
And canUnderstand: ? Or is that being too picky?
I did not know about #dictionaryClass:. That's a powerful hook.
Best, Marcel Am 09.11.2020 03:07:54 schrieb Levente Uzonyi <leves@caesar.elte.hu [mailto:leves@caesar.elte.hu]>: Hi Christoph,
On Sun, 8 Nov 2020, Christoph Thiede wrote:
Hi Levente,
would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be great because I depend on this functionality in another project and currently require your JSON fork in my baseline. :-)
I cannot merge it because that would bring back long removed methods, and MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:.
What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should
JsonObject new respondsTo: #foo:
return false? What should the following return?
JsonObject new foo: 1; respondsTo: #foo:
Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.:
JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject'
PseudoObject >> respondsTo: aSymbol
^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol]
(Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true"
Levente
Best, Christoph
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html [http://forum.world.st/Squeak-Dev-f45488.html]
--
_,,,^..^,,,_
best, Eliot
Hi all,
And canUnderstand: ? Or is that being too picky?
If the doesNotUnderstand: is not visible externally then who cares? Isn't the contract (o respondsTo: m) ifFalse: [self should: [o m] raise: MessageNotUnderstood]], or respondsTo: not implies MNU ?
http://www.hpi.de/ Well, my conception of the general contract would be exactly the following:
(o class canUnderstand: m) ifTrue: [ self assert: [o respondsTo: m]]. (o respondsTo: m) ifFalse: [ self deny: [o class canUnderstand: m]]. (o respondsTo: m) ifTrue: [ self shouldnt: [o m] raise: MessageNotUnderstood]. [o m] on: MessageNotUnderstood do: [ self deny: [o respondsTo: m]].
But I would *not* require the other direction of the implication - for #canUnderstand:, this is simply not possible for dynamic forwarding (unless we make false promises on the class side), and in my opinion, the current discussion shows that the same argument applies for the second statement, too.
I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?
IMHO, this goes beyond syntactic sugar. :-) As I tried to explain below, a proper implementation of #respondsTo: could be an essential prerequisite for using JsonObjects polymorphically with first-class object instances. In my use case, this is a crucial feature and if my proposal is discarded, I will have to subclass JsonObject ...
Best, Christoph ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 10. November 2020 09:34:49 An: squeak-dev Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project
and generate the getter setter on demand (via doesNotUnderstand:)
That's what I opted for, too, in: https://github.com/hpi-swa/MessageSendRecorder 's MessageSendRecordExtension.
Best. Marcel
Am 10.11.2020 09:32:07 schrieb Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
Hi all, for importing Matlab struct, I create classes on the fly and generate the getter setter on demand (via doesNotUnderstand:) See MatFileReader package in http://www.squeaksource.com/STEM.html
Le mar. 10 nov. 2020 à 09:06, Marcel Taeumel <marcel.taeumel@hpi.demailto:marcel.taeumel@hpi.de> a écrit :
And canUnderstand: ? Or is that being too picky?
Ah, right. On the class level, it would be like Levente inferred from my suggestion. I only thought of #respondsTo: to answer "true" only for the simple setter/getters that have keys present in the actual dictionary instance. Hmmm.....
I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?
Best, Marcel
Am 09.11.2020 21:08:14 schrieb Eliot Miranda <eliot.miranda@gmail.commailto:eliot.miranda@gmail.com>:
On Sun, Nov 8, 2020 at 11:04 PM Marcel Taeumel <marcel.taeumel@hpi.demailto:marcel.taeumel@hpi.de> wrote: Hi Levente.
Sounds right. If an object can answer to some extra messages via #doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash.
And canUnderstand: ? Or is that being too picky?
I did not know about #dictionaryClass:. That's a powerful hook.
Best, Marcel
Am 09.11.2020 03:07:54 schrieb Levente Uzonyi <leves@caesar.elte.humailto:leves@caesar.elte.hu>:
Hi Christoph,
On Sun, 8 Nov 2020, Christoph Thiede wrote:
Hi Levente,
would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be great because I depend on this functionality in another project and currently require your JSON fork in my baseline. :-)
I cannot merge it because that would bring back long removed methods, and MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:.
What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should
JsonObject new respondsTo: #foo:
return false? What should the following return?
JsonObject new foo: 1; respondsTo: #foo:
Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.:
JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject'
PseudoObject >> respondsTo: aSymbol
^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol]
(Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true"
Levente
Best, Christoph
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
-- _,,,^..^,,,_ best, Eliot
Hi all.
I am in favor of adding JsonDynamicObject (or similar) which has those extra features. I would avoid putting that stuff into JsonObject. When parsing a JSON file, the dictionary class can be configured anyway.
Best, Marcel Am 10.11.2020 10:16:50 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi all,
And canUnderstand: ? Or is that being too picky?
If the doesNotUnderstand: is not visible externally then who cares? Isn't the contract (o respondsTo: m) ifFalse: [self should: [o m] raise: MessageNotUnderstood]], or respondsTo: not implies MNU ?
[http://www.hpi.de/] Well, my conception of the general contract would be exactly the following:
(o class canUnderstand: m) ifTrue: [ self assert: [o respondsTo: m]]. (o respondsTo: m) ifFalse: [ self deny: [o class canUnderstand: m]]. (o respondsTo: m) ifTrue: [ self shouldnt: [o m] raise: MessageNotUnderstood]. [o m] on: MessageNotUnderstood do: [ self deny: [o respondsTo: m]].
But I would *not* require the other direction of the implication - for #canUnderstand:, this is simply not possible for dynamic forwarding (unless we make false promises on the class side), and in my opinion, the current discussion shows that the same argument applies for the second statement, too.
I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?
IMHO, this goes beyond syntactic sugar. :-) As I tried to explain below, a proper implementation of #respondsTo: could be an essential prerequisite for using JsonObjects polymorphically with first-class object instances. In my use case, this is a crucial feature and if my proposal is discarded, I will have to subclass JsonObject ...
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 10. November 2020 09:34:49 An: squeak-dev Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project
and generate the getter setter on demand (via doesNotUnderstand:)
That's what I opted for, too, in: https://github.com/hpi-swa/MessageSendRecorder [https://github.com/hpi-swa/MessageSendRecorder%5D%C2%A0%27s MessageSendRecordExtension.
Best. Marcel Am 10.11.2020 09:32:07 schrieb Nicolas Cellier nicolas.cellier.aka.nice@gmail.com: Hi all, for importing Matlab struct, I create classes on the fly and generate the getter setter on demand (via doesNotUnderstand:)
See MatFileReader package in http://www.squeaksource.com/STEM.html [http://www.squeaksource.com/STEM.html]
Le mar. 10 nov. 2020 à 09:06, Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> a écrit :
And canUnderstand: ? Or is that being too picky?
Ah, right. On the class level, it would be like Levente inferred from my suggestion. I only thought of #respondsTo: to answer "true" only for the simple setter/getters that have keys present in the actual dictionary instance. Hmmm.....
I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?
Best, Marcel Am 09.11.2020 21:08:14 schrieb Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]>:
On Sun, Nov 8, 2020 at 11:04 PM Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Hi Levente.
Sounds right. If an object can answer to some extra messages via #doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash.
And canUnderstand: ? Or is that being too picky?
I did not know about #dictionaryClass:. That's a powerful hook.
Best, Marcel Am 09.11.2020 03:07:54 schrieb Levente Uzonyi <leves@caesar.elte.hu [mailto:leves@caesar.elte.hu]>: Hi Christoph,
On Sun, 8 Nov 2020, Christoph Thiede wrote:
Hi Levente,
would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be great because I depend on this functionality in another project and currently require your JSON fork in my baseline. :-)
I cannot merge it because that would bring back long removed methods, and MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:.
What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should
JsonObject new respondsTo: #foo:
return false? What should the following return?
JsonObject new foo: 1; respondsTo: #foo:
Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.:
JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject'
PseudoObject >> respondsTo: aSymbol
^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol]
(Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true"
Levente
Best, Christoph
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html [http://forum.world.st/Squeak-Dev-f45488.html]
--
_,,,^..^,,,_
best, Eliot
Hi Marcel,
so do you propose to remove the existing implementation of dynamic forwarding from JsonObject, too (or more precisely, pull it down into DynamicJsonObject)? If yes, I would worry about compatibility problems. If no, I do not quite understand why one should override #doesNotUnderstand: but not #respondsTo: in a class. It seems a reasonable pattern for me to override them only together. :-)
Best,
Christoph
http://www.hpi.de/ ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 12. November 2020 10:07:28 An: squeak-dev Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project
Hi all.
I am in favor of adding JsonDynamicObject (or similar) which has those extra features. I would avoid putting that stuff into JsonObject. When parsing a JSON file, the dictionary class can be configured anyway.
Best, Marcel
Am 10.11.2020 10:16:50 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi all,
And canUnderstand: ? Or is that being too picky?
If the doesNotUnderstand: is not visible externally then who cares? Isn't the contract (o respondsTo: m) ifFalse: [self should: [o m] raise: MessageNotUnderstood]], or respondsTo: not implies MNU ?
http://www.hpi.de/ Well, my conception of the general contract would be exactly the following:
(o class canUnderstand: m) ifTrue: [ self assert: [o respondsTo: m]]. (o respondsTo: m) ifFalse: [ self deny: [o class canUnderstand: m]]. (o respondsTo: m) ifTrue: [ self shouldnt: [o m] raise: MessageNotUnderstood]. [o m] on: MessageNotUnderstood do: [ self deny: [o respondsTo: m]].
But I would *not* require the other direction of the implication - for #canUnderstand:, this is simply not possible for dynamic forwarding (unless we make false promises on the class side), and in my opinion, the current discussion shows that the same argument applies for the second statement, too.
I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?
IMHO, this goes beyond syntactic sugar. :-) As I tried to explain below, a proper implementation of #respondsTo: could be an essential prerequisite for using JsonObjects polymorphically with first-class object instances. In my use case, this is a crucial feature and if my proposal is discarded, I will have to subclass JsonObject ...
Best, Christoph ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 10. November 2020 09:34:49 An: squeak-dev Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project
and generate the getter setter on demand (via doesNotUnderstand:)
That's what I opted for, too, in: https://github.com/hpi-swa/MessageSendRecorder 's MessageSendRecordExtension.
Best. Marcel
Am 10.11.2020 09:32:07 schrieb Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
Hi all, for importing Matlab struct, I create classes on the fly and generate the getter setter on demand (via doesNotUnderstand:) See MatFileReader package in http://www.squeaksource.com/STEM.html
Le mar. 10 nov. 2020 à 09:06, Marcel Taeumel <marcel.taeumel@hpi.demailto:marcel.taeumel@hpi.de> a écrit :
And canUnderstand: ? Or is that being too picky?
Ah, right. On the class level, it would be like Levente inferred from my suggestion. I only thought of #respondsTo: to answer "true" only for the simple setter/getters that have keys present in the actual dictionary instance. Hmmm.....
I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?
Best, Marcel
Am 09.11.2020 21:08:14 schrieb Eliot Miranda <eliot.miranda@gmail.commailto:eliot.miranda@gmail.com>:
On Sun, Nov 8, 2020 at 11:04 PM Marcel Taeumel <marcel.taeumel@hpi.demailto:marcel.taeumel@hpi.de> wrote: Hi Levente.
Sounds right. If an object can answer to some extra messages via #doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash.
And canUnderstand: ? Or is that being too picky?
I did not know about #dictionaryClass:. That's a powerful hook.
Best, Marcel
Am 09.11.2020 03:07:54 schrieb Levente Uzonyi <leves@caesar.elte.humailto:leves@caesar.elte.hu>:
Hi Christoph,
On Sun, 8 Nov 2020, Christoph Thiede wrote:
Hi Levente,
would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be great because I depend on this functionality in another project and currently require your JSON fork in my baseline. :-)
I cannot merge it because that would bring back long removed methods, and MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:.
What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should
JsonObject new respondsTo: #foo:
return false? What should the following return?
JsonObject new foo: 1; respondsTo: #foo:
Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.:
JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject'
PseudoObject >> respondsTo: aSymbol
^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol]
(Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true"
Levente
Best, Christoph
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
-- _,,,^..^,,,_ best, Eliot
(Depending on how this discussion will end, this reparented mcz file might be relevant to prevent further merging issues.) ________________________________ Von: Thiede, Christoph Gesendet: Montag, 16. November 2020 16:22:01 An: squeak-dev Betreff: AW: [squeak-dev] I'd like to contribute to the JSON project
Hi Marcel,
so do you propose to remove the existing implementation of dynamic forwarding from JsonObject, too (or more precisely, pull it down into DynamicJsonObject)? If yes, I would worry about compatibility problems. If no, I do not quite understand why one should override #doesNotUnderstand: but not #respondsTo: in a class. It seems a reasonable pattern for me to override them only together. :-)
Best,
Christoph
http://www.hpi.de/ ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 12. November 2020 10:07:28 An: squeak-dev Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project
Hi all.
I am in favor of adding JsonDynamicObject (or similar) which has those extra features. I would avoid putting that stuff into JsonObject. When parsing a JSON file, the dictionary class can be configured anyway.
Best, Marcel
Am 10.11.2020 10:16:50 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi all,
And canUnderstand: ? Or is that being too picky?
If the doesNotUnderstand: is not visible externally then who cares? Isn't the contract (o respondsTo: m) ifFalse: [self should: [o m] raise: MessageNotUnderstood]], or respondsTo: not implies MNU ?
http://www.hpi.de/ Well, my conception of the general contract would be exactly the following:
(o class canUnderstand: m) ifTrue: [ self assert: [o respondsTo: m]]. (o respondsTo: m) ifFalse: [ self deny: [o class canUnderstand: m]]. (o respondsTo: m) ifTrue: [ self shouldnt: [o m] raise: MessageNotUnderstood]. [o m] on: MessageNotUnderstood do: [ self deny: [o respondsTo: m]].
But I would *not* require the other direction of the implication - for #canUnderstand:, this is simply not possible for dynamic forwarding (unless we make false promises on the class side), and in my opinion, the current discussion shows that the same argument applies for the second statement, too.
I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?
IMHO, this goes beyond syntactic sugar. :-) As I tried to explain below, a proper implementation of #respondsTo: could be an essential prerequisite for using JsonObjects polymorphically with first-class object instances. In my use case, this is a crucial feature and if my proposal is discarded, I will have to subclass JsonObject ...
Best, Christoph ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 10. November 2020 09:34:49 An: squeak-dev Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project
and generate the getter setter on demand (via doesNotUnderstand:)
That's what I opted for, too, in: https://github.com/hpi-swa/MessageSendRecorder 's MessageSendRecordExtension.
Best. Marcel
Am 10.11.2020 09:32:07 schrieb Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
Hi all, for importing Matlab struct, I create classes on the fly and generate the getter setter on demand (via doesNotUnderstand:) See MatFileReader package in http://www.squeaksource.com/STEM.html
Le mar. 10 nov. 2020 à 09:06, Marcel Taeumel <marcel.taeumel@hpi.demailto:marcel.taeumel@hpi.de> a écrit :
And canUnderstand: ? Or is that being too picky?
Ah, right. On the class level, it would be like Levente inferred from my suggestion. I only thought of #respondsTo: to answer "true" only for the simple setter/getters that have keys present in the actual dictionary instance. Hmmm.....
I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?
Best, Marcel
Am 09.11.2020 21:08:14 schrieb Eliot Miranda <eliot.miranda@gmail.commailto:eliot.miranda@gmail.com>:
On Sun, Nov 8, 2020 at 11:04 PM Marcel Taeumel <marcel.taeumel@hpi.demailto:marcel.taeumel@hpi.de> wrote: Hi Levente.
Sounds right. If an object can answer to some extra messages via #doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash.
And canUnderstand: ? Or is that being too picky?
I did not know about #dictionaryClass:. That's a powerful hook.
Best, Marcel
Am 09.11.2020 03:07:54 schrieb Levente Uzonyi <leves@caesar.elte.humailto:leves@caesar.elte.hu>:
Hi Christoph,
On Sun, 8 Nov 2020, Christoph Thiede wrote:
Hi Levente,
would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be great because I depend on this functionality in another project and currently require your JSON fork in my baseline. :-)
I cannot merge it because that would bring back long removed methods, and MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:.
What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should
JsonObject new respondsTo: #foo:
return false? What should the following return?
JsonObject new foo: 1; respondsTo: #foo:
Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.:
JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject'
PseudoObject >> respondsTo: aSymbol
^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol]
(Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true"
Levente
Best, Christoph
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
-- _,,,^..^,,,_ best, Eliot
Hi All,
Since most (every?) practical use of #respondsTo: is to check whether it's safe to send the message or not, I think, contrary to what was mentioned in this thread, that #respondsTo: does not have to return true when sending the message would not result in an MNU. So, I suggest adding the following implementation to expose the dynamic nature of JsonObject:
JsonObject >> #respondsTo: aSymbol
| precedence | (super respondsTo: aSymbol) ifTrue: [ ^true ]. (precedence := aSymbol precedence) = 1 ifTrue: [ ^self includesKey: aSymbol ]. (precedence = 3 and: [ (aSymbol indexOf: $:) = aSymbol size ]) ifTrue: [ ^self includesKey: aSymbol allButLast ]. ^false
Levente
On Sun, 22 Nov 2020, Thiede, Christoph wrote:
(Depending on how this discussion will end, this reparented mcz file might be relevant to prevent further merging issues.)
Von: Thiede, Christoph Gesendet: Montag, 16. November 2020 16:22:01 An: squeak-dev Betreff: AW: [squeak-dev] I'd like to contribute to the JSON project
Hi Marcel,
so do you propose to remove the existing implementation of dynamic forwarding from JsonObject, too (or more precisely, pull it down into DynamicJsonObject)? If yes, I would worry about compatibility problems. If no, I do not quite understand why one should override #doesNotUnderstand: but not #respondsTo: in a class. It seems a reasonable pattern for me to override them only together. :-)
Best,
Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 12. November 2020 10:07:28 An: squeak-dev Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project Hi all. I am in favor of adding JsonDynamicObject (or similar) which has those extra features. I would avoid putting that stuff into JsonObject. When parsing a JSON file, the dictionary class can be configured anyway.
Best, Marcel
Am 10.11.2020 10:16:50 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.de>: Hi all, > And canUnderstand: ? Or is that being too picky? > If the doesNotUnderstand: is not visible externally then who cares? Isn't the contract (o respondsTo: m) ifFalse: [self should: [o m] raise: MessageNotUnderstood]], or respondsTo: not implies MNU ?
Well, my conception of the general contract would be exactly the following:
(o class canUnderstand: m) ifTrue: [ self assert: [o respondsTo: m]]. (o respondsTo: m) ifFalse: [ self deny: [o class canUnderstand: m]]. (o respondsTo: m) ifTrue: [ self shouldnt: [o m] raise: MessageNotUnderstood]. [o m] on: MessageNotUnderstood do: [ self deny: [o respondsTo: m]].
But I would *not* require the other direction of the implication - for #canUnderstand:, this is simply not possible for dynamic forwarding (unless we make false promises on the class side), and in my opinion, the current discussion shows that the same argument applies for the second statement, too.
I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?
IMHO, this goes beyond syntactic sugar. :-) As I tried to explain below, a proper implementation of #respondsTo: could be an essential prerequisite for using JsonObjects polymorphically with first-class object instances. In my use case, this is a crucial feature and if my proposal is discarded, I will have to subclass JsonObject ...
Best, Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 10. November 2020 09:34:49 An: squeak-dev Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project
and generate the getter setter on demand (via doesNotUnderstand:)
That's what I opted for, too, in: https://github.com/hpi-swa/MessageSendRecorder%C2%A0%27s MessageSendRecordExtension.
Best. Marcel
Am 10.11.2020 09:32:07 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>: Hi all,
for importing Matlab struct, I create classes on the fly and generate the getter setter on demand (via doesNotUnderstand:) See MatFileReader package in http://www.squeaksource.com/STEM.html
Le mar. 10 nov. 2020 à 09:06, Marcel Taeumel marcel.taeumel@hpi.de a écrit : > And canUnderstand: ? Or is that being too picky? Ah, right. On the class level, it would be like Levente inferred from my suggestion. I only thought of #respondsTo: to answer "true" only for the simple setter/getters that have keys present in the actual dictionary instance. Hmmm.....
I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?
Best, Marcel
Am 09.11.2020 21:08:14 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
On Sun, Nov 8, 2020 at 11:04 PM Marcel Taeumel marcel.taeumel@hpi.de wrote: Hi Levente. Sounds right. If an object can answer to some extra messages via #doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash.
And canUnderstand: ? Or is that being too picky?
I did not know about #dictionaryClass:. That's a powerful hook.
Best, Marcel
Am 09.11.2020 03:07:54 schrieb Levente Uzonyi <leves@caesar.elte.hu>: Hi Christoph, On Sun, 8 Nov 2020, Christoph Thiede wrote: > Hi Levente, > > would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be > great because I depend on this functionality in another project and > currently require your JSON fork in my baseline. :-) I cannot merge it because that would bring back long removed methods, and MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:. What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should JsonObject new respondsTo: #foo: return false? What should the following return? JsonObject new foo: 1; respondsTo: #foo: Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.: JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject' PseudoObject >> respondsTo: aSymbol ^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol] (Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true" Levente > > Best, > Christoph > > > > -- > Sent from: http://forum.world.st/Squeak-Dev-f45488.html
-- _,,,^..^,,,_ best, Eliot
On 22. Nov 2020, at 17:46, Levente Uzonyi leves@caesar.elte.hu wrote:
Hi All,
Since most (every?) practical use of #respondsTo: is to check whether it's safe to send the message or not, I think, contrary to what was mentioned in this thread, that #respondsTo: does not have to return true when sending the message would not result in an MNU. So, I suggest adding the following implementation to expose the dynamic nature of JsonObject:
JsonObject >> #respondsTo: aSymbol
| precedence | (super respondsTo: aSymbol) ifTrue: [ ^true ]. (precedence := aSymbol precedence) = 1 ifTrue: [ ^self includesKey: aSymbol ]. (precedence = 3 and: [ (aSymbol indexOf: $:) = aSymbol size ]) ifTrue: [ ^self includesKey: aSymbol allButLast ]. ^false
That's nice! but why not make it simpler?
JsonObject >> #respondsTo: aSymbol
| precedence | (super respondsTo: aSymbol) ifTrue: [ ^true ]. aSymbol isSimpleGetter ifTrue: [^self includesKey: aSymbol]. aSymbol isSimpleSetter ifTrue: [^self includesKey: aSymbol asSimpleGetter]. ^false
-Tobias
Levente
On Sun, 22 Nov 2020, Thiede, Christoph wrote:
(Depending on how this discussion will end, this reparented mcz file might be relevant to prevent further merging issues.) _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Von: Thiede, Christoph Gesendet: Montag, 16. November 2020 16:22:01 An: squeak-dev Betreff: AW: [squeak-dev] I'd like to contribute to the JSON project Hi Marcel, so do you propose to remove the existing implementation of dynamic forwarding from JsonObject, too (or more precisely, pull it down into DynamicJsonObject)? If yes, I would worry about compatibility problems. If no, I do not quite understand why one should override #doesNotUnderstand: but not #respondsTo: in a class. It seems a reasonable pattern for me to override them only together. :-) Best, Christoph _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 12. November 2020 10:07:28 An: squeak-dev Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project Hi all. I am in favor of adding JsonDynamicObject (or similar) which has those extra features. I would avoid putting that stuff into JsonObject. When parsing a JSON file, the dictionary class can be configured anyway. Best, Marcel
Am 10.11.2020 10:16:50 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.de>: Hi all, > And canUnderstand: ? Or is that being too picky? > If the doesNotUnderstand: is not visible externally then who cares? Isn't the contract (o respondsTo: m) ifFalse: [self should: [o m] raise: MessageNotUnderstood]], or respondsTo: not implies MNU ?
Well, my conception of the general contract would be exactly the following: (o class canUnderstand: m) ifTrue: [ self assert: [o respondsTo: m]]. (o respondsTo: m) ifFalse: [ self deny: [o class canUnderstand: m]]. (o respondsTo: m) ifTrue: [ self shouldnt: [o m] raise: MessageNotUnderstood]. [o m] on: MessageNotUnderstood do: [ self deny: [o respondsTo: m]]. But I would *not* require the other direction of the implication - for #canUnderstand:, this is simply not possible for dynamic forwarding (unless we make false promises on the class side), and in my opinion, the current discussion shows that the same argument applies for the second statement, too.
I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?
IMHO, this goes beyond syntactic sugar. :-) As I tried to explain below, a proper implementation of #respondsTo: could be an essential prerequisite for using JsonObjects polymorphically with first-class object instances. In my use case, this is a crucial feature and if my proposal is discarded, I will have to subclass JsonObject ... Best, Christoph _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 10. November 2020 09:34:49 An: squeak-dev Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project
and generate the getter setter on demand (via doesNotUnderstand:)
That's what I opted for, too, in: https://github.com/hpi-swa/MessageSendRecorder 's MessageSendRecordExtension. Best. Marcel
Am 10.11.2020 09:32:07 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>: Hi all,
for importing Matlab struct, I create classes on the fly and generate the getter setter on demand (via doesNotUnderstand:) See MatFileReader package in http://www.squeaksource.com/STEM.html Le mar. 10 nov. 2020 à 09:06, Marcel Taeumel marcel.taeumel@hpi.de a écrit : > And canUnderstand: ? Or is that being too picky? Ah, right. On the class level, it would be like Levente inferred from my suggestion. I only thought of #respondsTo: to answer "true" only for the simple setter/getters that have keys present in the actual dictionary instance. Hmmm..... I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right? Best, Marcel
Am 09.11.2020 21:08:14 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
On Sun, Nov 8, 2020 at 11:04 PM Marcel Taeumel marcel.taeumel@hpi.de wrote: Hi Levente. Sounds right. If an object can answer to some extra messages via #doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash. And canUnderstand: ? Or is that being too picky? I did not know about #dictionaryClass:. That's a powerful hook. Best, Marcel
Am 09.11.2020 03:07:54 schrieb Levente Uzonyi <leves@caesar.elte.hu>: Hi Christoph, On Sun, 8 Nov 2020, Christoph Thiede wrote: > Hi Levente, > > would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be > great because I depend on this functionality in another project and > currently require your JSON fork in my baseline. :-) I cannot merge it because that would bring back long removed methods, and MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:. What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should JsonObject new respondsTo: #foo: return false? What should the following return? JsonObject new foo: 1; respondsTo: #foo: Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.: JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject' PseudoObject >> respondsTo: aSymbol ^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol] (Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true" Levente > > Best, > Christoph > > > > -- > Sent from: http://forum.world.st/Squeak-Dev-f45488.html
-- _,,,^..^,,,_ best, Eliot
+1 for Levente's implementation proposal, and +1 for Tobias's refactoring proposal (it might be a few byte steps longer, but readability first ;-)).
Best,
Christoph
http://www.hpi.de/ ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Tobias Pape Das.Linux@gmx.de Gesendet: Sonntag, 22. November 2020 18:03:35 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project
On 22. Nov 2020, at 17:46, Levente Uzonyi leves@caesar.elte.hu wrote:
Hi All,
Since most (every?) practical use of #respondsTo: is to check whether it's safe to send the message or not, I think, contrary to what was mentioned in this thread, that #respondsTo: does not have to return true when sending the message would not result in an MNU. So, I suggest adding the following implementation to expose the dynamic nature of JsonObject:
JsonObject >> #respondsTo: aSymbol
| precedence | (super respondsTo: aSymbol) ifTrue: [ ^true ]. (precedence := aSymbol precedence) = 1 ifTrue: [ ^self includesKey: aSymbol ]. (precedence = 3 and: [ (aSymbol indexOf: $:) = aSymbol size ]) ifTrue: [ ^self includesKey: aSymbol allButLast ]. ^false
That's nice! but why not make it simpler?
JsonObject >> #respondsTo: aSymbol
| precedence | (super respondsTo: aSymbol) ifTrue: [ ^true ]. aSymbol isSimpleGetter ifTrue: [^self includesKey: aSymbol]. aSymbol isSimpleSetter ifTrue: [^self includesKey: aSymbol asSimpleGetter]. ^false
-Tobias
Levente
On Sun, 22 Nov 2020, Thiede, Christoph wrote:
(Depending on how this discussion will end, this reparented mcz file might be relevant to prevent further merging issues.) _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Von: Thiede, Christoph Gesendet: Montag, 16. November 2020 16:22:01 An: squeak-dev Betreff: AW: [squeak-dev] I'd like to contribute to the JSON project Hi Marcel, so do you propose to remove the existing implementation of dynamic forwarding from JsonObject, too (or more precisely, pull it down into DynamicJsonObject)? If yes, I would worry about compatibility problems. If no, I do not quite understand why one should override #doesNotUnderstand: but not #respondsTo: in a class. It seems a reasonable pattern for me to override them only together. :-) Best, Christoph _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 12. November 2020 10:07:28 An: squeak-dev Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project Hi all. I am in favor of adding JsonDynamicObject (or similar) which has those extra features. I would avoid putting that stuff into JsonObject. When parsing a JSON file, the dictionary class can be configured anyway. Best, Marcel
Am 10.11.2020 10:16:50 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.de>: Hi all, > And canUnderstand: ? Or is that being too picky? > If the doesNotUnderstand: is not visible externally then who cares? Isn't the contract (o respondsTo: m) ifFalse: [self should: [o m] raise: MessageNotUnderstood]], or respondsTo: not implies MNU ?
Well, my conception of the general contract would be exactly the following: (o class canUnderstand: m) ifTrue: [ self assert: [o respondsTo: m]]. (o respondsTo: m) ifFalse: [ self deny: [o class canUnderstand: m]]. (o respondsTo: m) ifTrue: [ self shouldnt: [o m] raise: MessageNotUnderstood]. [o m] on: MessageNotUnderstood do: [ self deny: [o respondsTo: m]]. But I would *not* require the other direction of the implication - for #canUnderstand:, this is simply not possible for dynamic forwarding (unless we make false promises on the class side), and in my opinion, the current discussion shows that the same argument applies for the second statement, too.
I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?
IMHO, this goes beyond syntactic sugar. :-) As I tried to explain below, a proper implementation of #respondsTo: could be an essential prerequisite for using JsonObjects polymorphically with first-class object instances. In my use case, this is a crucial feature and if my proposal is discarded, I will have to subclass JsonObject ... Best, Christoph _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 10. November 2020 09:34:49 An: squeak-dev Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project
and generate the getter setter on demand (via doesNotUnderstand:)
That's what I opted for, too, in: https://github.com/hpi-swa/MessageSendRecorder 's MessageSendRecordExtension. Best. Marcel
Am 10.11.2020 09:32:07 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>: Hi all,
for importing Matlab struct, I create classes on the fly and generate the getter setter on demand (via doesNotUnderstand:) See MatFileReader package in http://www.squeaksource.com/STEM.html Le mar. 10 nov. 2020 à 09:06, Marcel Taeumel marcel.taeumel@hpi.de a écrit : > And canUnderstand: ? Or is that being too picky? Ah, right. On the class level, it would be like Levente inferred from my suggestion. I only thought of #respondsTo: to answer "true" only for the simple setter/getters that have keys present in the actual dictionary instance. Hmmm..... I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right? Best, Marcel
Am 09.11.2020 21:08:14 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
On Sun, Nov 8, 2020 at 11:04 PM Marcel Taeumel marcel.taeumel@hpi.de wrote: Hi Levente. Sounds right. If an object can answer to some extra messages via #doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash. And canUnderstand: ? Or is that being too picky? I did not know about #dictionaryClass:. That's a powerful hook. Best, Marcel
Am 09.11.2020 03:07:54 schrieb Levente Uzonyi <leves@caesar.elte.hu>: Hi Christoph, On Sun, 8 Nov 2020, Christoph Thiede wrote: > Hi Levente, > > would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be > great because I depend on this functionality in another project and > currently require your JSON fork in my baseline. :-) I cannot merge it because that would bring back long removed methods, and MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:. What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should JsonObject new respondsTo: #foo: return false? What should the following return? JsonObject new foo: 1; respondsTo: #foo: Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.: JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject' PseudoObject >> respondsTo: aSymbol ^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol] (Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true" Levente > > Best, > Christoph > > > > -- > Sent from: http://forum.world.st/Squeak-Dev-f45488.html
-- _,,,^..^,,,_ best, Eliot
Hi Tobias,
On Sun, 22 Nov 2020, Tobias Pape wrote:
On 22. Nov 2020, at 17:46, Levente Uzonyi leves@caesar.elte.hu wrote:
Hi All,
Since most (every?) practical use of #respondsTo: is to check whether it's safe to send the message or not, I think, contrary to what was mentioned in this thread, that #respondsTo: does not have to return true when sending the message would not result in an MNU. So, I suggest adding the following implementation to expose the dynamic nature of JsonObject:
JsonObject >> #respondsTo: aSymbol
| precedence | (super respondsTo: aSymbol) ifTrue: [ ^true ]. (precedence := aSymbol precedence) = 1 ifTrue: [ ^self includesKey: aSymbol ]. (precedence = 3 and: [ (aSymbol indexOf: $:) = aSymbol size ]) ifTrue: [ ^self includesKey: aSymbol allButLast ]. ^false
That's nice! but why not make it simpler?
JsonObject >> #respondsTo: aSymbol
| precedence | (super respondsTo: aSymbol) ifTrue: [ ^true ]. aSymbol isSimpleGetter ifTrue: [^self includesKey: aSymbol]. aSymbol isSimpleSetter ifTrue: [^self includesKey: aSymbol asSimpleGetter]. ^false
Three reasons:
1. performance
| j s | Smalltalk garbageCollect. j := JsonObject new foo: 1; bar: 2; baz: 3; yourself. s := Symbol allSymbols. { [ s do: [ :each | ] ] bench. [ s do: [ :each | j respondsTo: each ] ] bench. [ s do: [ :each | j respondsTo2: each ] ] bench. "Your suggested implementation" } #( '1,630 per second. 613 microseconds per run. 0 % GC time.' '19 per second. 52.7 milliseconds per run. 0.09992 % GC time.' '1.18 per second. 850 milliseconds per run. 32.81709 % GC time.' )
Okay, that may not be too a realistic workload. The reason of the extreme slowdown and high GC time is rapid interning and GCing of Symbols created by #asSimpleGetter.
If you change s to a handcrafted array that avoids Symbol creation, like
s := #(yourself foo foo: bar bar: baz baz: foobar foobar: name name:)
the numbers get better but still not as good as my suggestion:
#( '4,970,000 per second. 201 nanoseconds per run. 38.02 % GC time.' '147,000 per second. 6.82 microseconds per run. 1.74 % GC time.' '92,300 per second. 10.8 microseconds per run. 1.09978 % GC time.')
2. backwards compatibility #isSimpleSetter and #isSimpleGetter are available since Squeak 5.3. I use this code in 5.1 and 5.2 images as well.
3. to use the same mechanism as #doesNotUnderstand: Have a look at that method.
Levente
-Tobias
Levente
On Sun, 22 Nov 2020, Thiede, Christoph wrote:
(Depending on how this discussion will end, this reparented mcz file might be relevant to prevent further merging issues.) _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Von: Thiede, Christoph Gesendet: Montag, 16. November 2020 16:22:01 An: squeak-dev Betreff: AW: [squeak-dev] I'd like to contribute to the JSON project Hi Marcel, so do you propose to remove the existing implementation of dynamic forwarding from JsonObject, too (or more precisely, pull it down into DynamicJsonObject)? If yes, I would worry about compatibility problems. If no, I do not quite understand why one should override #doesNotUnderstand: but not #respondsTo: in a class. It seems a reasonable pattern for me to override them only together. :-) Best, Christoph _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 12. November 2020 10:07:28 An: squeak-dev Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project Hi all. I am in favor of adding JsonDynamicObject (or similar) which has those extra features. I would avoid putting that stuff into JsonObject. When parsing a JSON file, the dictionary class can be configured anyway. Best, Marcel
Am 10.11.2020 10:16:50 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.de>: Hi all, > And canUnderstand: ? Or is that being too picky? > If the doesNotUnderstand: is not visible externally then who cares? Isn't the contract (o respondsTo: m) ifFalse: [self should: [o m] raise: MessageNotUnderstood]], or respondsTo: not implies MNU ?
Well, my conception of the general contract would be exactly the following: (o class canUnderstand: m) ifTrue: [ self assert: [o respondsTo: m]]. (o respondsTo: m) ifFalse: [ self deny: [o class canUnderstand: m]]. (o respondsTo: m) ifTrue: [ self shouldnt: [o m] raise: MessageNotUnderstood]. [o m] on: MessageNotUnderstood do: [ self deny: [o respondsTo: m]]. But I would *not* require the other direction of the implication - for #canUnderstand:, this is simply not possible for dynamic forwarding (unless we make false promises on the class side), and in my opinion, the current discussion shows that the same argument applies for the second statement, too.
I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?
IMHO, this goes beyond syntactic sugar. :-) As I tried to explain below, a proper implementation of #respondsTo: could be an essential prerequisite for using JsonObjects polymorphically with first-class object instances. In my use case, this is a crucial feature and if my proposal is discarded, I will have to subclass JsonObject ... Best, Christoph _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 10. November 2020 09:34:49 An: squeak-dev Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project
and generate the getter setter on demand (via doesNotUnderstand:)
That's what I opted for, too, in: https://github.com/hpi-swa/MessageSendRecorder 's MessageSendRecordExtension. Best. Marcel
Am 10.11.2020 09:32:07 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>: Hi all,
for importing Matlab struct, I create classes on the fly and generate the getter setter on demand (via doesNotUnderstand:) See MatFileReader package in http://www.squeaksource.com/STEM.html Le mar. 10 nov. 2020 à 09:06, Marcel Taeumel marcel.taeumel@hpi.de a écrit : > And canUnderstand: ? Or is that being too picky? Ah, right. On the class level, it would be like Levente inferred from my suggestion. I only thought of #respondsTo: to answer "true" only for the simple setter/getters that have keys present in the actual dictionary instance. Hmmm..... I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right? Best, Marcel
Am 09.11.2020 21:08:14 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
On Sun, Nov 8, 2020 at 11:04 PM Marcel Taeumel marcel.taeumel@hpi.de wrote: Hi Levente. Sounds right. If an object can answer to some extra messages via #doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash. And canUnderstand: ? Or is that being too picky? I did not know about #dictionaryClass:. That's a powerful hook. Best, Marcel
Am 09.11.2020 03:07:54 schrieb Levente Uzonyi <leves@caesar.elte.hu>: Hi Christoph, On Sun, 8 Nov 2020, Christoph Thiede wrote: > Hi Levente, > > would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be > great because I depend on this functionality in another project and > currently require your JSON fork in my baseline. :-) I cannot merge it because that would bring back long removed methods, and MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:. What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should JsonObject new respondsTo: #foo: return false? What should the following return? JsonObject new foo: 1; respondsTo: #foo: Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.: JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject' PseudoObject >> respondsTo: aSymbol ^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol] (Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true" Levente > > Best, > Christoph > > > > -- > Sent from: http://forum.world.st/Squeak-Dev-f45488.html
-- _,,,^..^,,,_ best, Eliot
On 22. Nov 2020, at 18:51, Levente Uzonyi leves@caesar.elte.hu wrote:
Hi Tobias,
On Sun, 22 Nov 2020, Tobias Pape wrote:
On 22. Nov 2020, at 17:46, Levente Uzonyi leves@caesar.elte.hu wrote: Hi All, Since most (every?) practical use of #respondsTo: is to check whether it's safe to send the message or not, I think, contrary to what was mentioned in this thread, that #respondsTo: does not have to return true when sending the message would not result in an MNU. So, I suggest adding the following implementation to expose the dynamic nature of JsonObject: JsonObject >> #respondsTo: aSymbol
| precedence | (super respondsTo: aSymbol) ifTrue: [ ^true ]. (precedence := aSymbol precedence) = 1 ifTrue: [ ^self includesKey: aSymbol ]. (precedence = 3 and: [ (aSymbol indexOf: $:) = aSymbol size ]) ifTrue: [ ^self includesKey: aSymbol allButLast ]. ^false
That's nice! but why not make it simpler?
JsonObject >> #respondsTo: aSymbol
| precedence | (super respondsTo: aSymbol) ifTrue: [ ^true ]. aSymbol isSimpleGetter ifTrue: [^self includesKey: aSymbol]. aSymbol isSimpleSetter ifTrue: [^self includesKey: aSymbol asSimpleGetter]. ^false
Three reasons:
- performance
| j s | Smalltalk garbageCollect. j := JsonObject new foo: 1; bar: 2; baz: 3; yourself. s := Symbol allSymbols. { [ s do: [ :each | ] ] bench. [ s do: [ :each | j respondsTo: each ] ] bench. [ s do: [ :each | j respondsTo2: each ] ] bench. "Your suggested implementation" } #( '1,630 per second. 613 microseconds per run. 0 % GC time.' '19 per second. 52.7 milliseconds per run. 0.09992 % GC time.' '1.18 per second. 850 milliseconds per run. 32.81709 % GC time.' )
Okay, that may not be too a realistic workload. The reason of the extreme slowdown and high GC time is rapid interning and GCing of Symbols created by #asSimpleGetter.
If you change s to a handcrafted array that avoids Symbol creation, like
s := #(yourself foo foo: bar bar: baz baz: foobar foobar: name name:)
the numbers get better but still not as good as my suggestion:
#( '4,970,000 per second. 201 nanoseconds per run. 38.02 % GC time.' '147,000 per second. 6.82 microseconds per run. 1.74 % GC time.' '92,300 per second. 10.8 microseconds per run. 1.09978 % GC time.')
I thought you'd say that. But "precedence" is one of the most obscure things around that part in the image.
- backwards compatibility
#isSimpleSetter and #isSimpleGetter are available since Squeak 5.3. I use this code in 5.1 and 5.2 images as well.
Yea, Pre 5.3 I'd have said #asMutator.
- to use the same mechanism as #doesNotUnderstand:
Have a look at that method.
Then I'd rather say change DNU too. If you're down that hole (dnu/respondsTo) anyways, I don't buy the performance argument anymore.
Not everything has to be as fast as possible.
Best regards -Tobias
Levente
-Tobias
Levente On Sun, 22 Nov 2020, Thiede, Christoph wrote:
(Depending on how this discussion will end, this reparented mcz file might be relevant to prevent further merging issues.) _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Von: Thiede, Christoph Gesendet: Montag, 16. November 2020 16:22:01 An: squeak-dev Betreff: AW: [squeak-dev] I'd like to contribute to the JSON project Hi Marcel, so do you propose to remove the existing implementation of dynamic forwarding from JsonObject, too (or more precisely, pull it down into DynamicJsonObject)? If yes, I would worry about compatibility problems. If no, I do not quite understand why one should override #doesNotUnderstand: but not #respondsTo: in a class. It seems a reasonable pattern for me to override them only together. :-) Best, Christoph _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 12. November 2020 10:07:28 An: squeak-dev Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project Hi all. I am in favor of adding JsonDynamicObject (or similar) which has those extra features. I would avoid putting that stuff into JsonObject. When parsing a JSON file, the dictionary class can be configured anyway. Best, Marcel
Am 10.11.2020 10:16:50 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.de>: Hi all, > And canUnderstand: ? Or is that being too picky? > If the doesNotUnderstand: is not visible externally then who cares? Isn't the contract (o respondsTo: m) ifFalse: [self should: [o m] raise: MessageNotUnderstood]], or respondsTo: not implies MNU ?
Well, my conception of the general contract would be exactly the following: (o class canUnderstand: m) ifTrue: [ self assert: [o respondsTo: m]]. (o respondsTo: m) ifFalse: [ self deny: [o class canUnderstand: m]]. (o respondsTo: m) ifTrue: [ self shouldnt: [o m] raise: MessageNotUnderstood]. [o m] on: MessageNotUnderstood do: [ self deny: [o respondsTo: m]]. But I would *not* require the other direction of the implication - for #canUnderstand:, this is simply not possible for dynamic forwarding (unless we make false promises on the class side), and in my opinion, the current discussion shows that the same argument applies for the second statement, too.
I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?
IMHO, this goes beyond syntactic sugar. :-) As I tried to explain below, a proper implementation of #respondsTo: could be an essential prerequisite for using JsonObjects polymorphically with first-class object instances. In my use case, this is a crucial feature and if my proposal is discarded, I will have to subclass JsonObject ... Best, Christoph _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 10. November 2020 09:34:49 An: squeak-dev Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project > and generate the getter setter on demand (via doesNotUnderstand:) That's what I opted for, too, in: https://github.com/hpi-swa/MessageSendRecorder 's MessageSendRecordExtension. Best. Marcel
Am 10.11.2020 09:32:07 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>: Hi all,
for importing Matlab struct, I create classes on the fly and generate the getter setter on demand (via doesNotUnderstand:) See MatFileReader package in http://www.squeaksource.com/STEM.html Le mar. 10 nov. 2020 à 09:06, Marcel Taeumel marcel.taeumel@hpi.de a écrit : > And canUnderstand: ? Or is that being too picky? Ah, right. On the class level, it would be like Levente inferred from my suggestion. I only thought of #respondsTo: to answer "true" only for the simple setter/getters that have keys present in the actual dictionary instance. Hmmm..... I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right? Best, Marcel
Am 09.11.2020 21:08:14 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
On Sun, Nov 8, 2020 at 11:04 PM Marcel Taeumel marcel.taeumel@hpi.de wrote: Hi Levente. Sounds right. If an object can answer to some extra messages via #doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash. And canUnderstand: ? Or is that being too picky? I did not know about #dictionaryClass:. That's a powerful hook. Best, Marcel
Am 09.11.2020 03:07:54 schrieb Levente Uzonyi <leves@caesar.elte.hu>: Hi Christoph, On Sun, 8 Nov 2020, Christoph Thiede wrote: > Hi Levente, > > would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be > great because I depend on this functionality in another project and > currently require your JSON fork in my baseline. :-) I cannot merge it because that would bring back long removed methods, and MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:. What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should JsonObject new respondsTo: #foo: return false? What should the following return? JsonObject new foo: 1; respondsTo: #foo: Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.: JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject' PseudoObject >> respondsTo: aSymbol ^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol] (Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true" Levente > > Best, > Christoph > > > > -- > Sent from: http://forum.world.st/Squeak-Dev-f45488.html
-- _,,,^..^,,,_ best, Eliot
Hi Tobias,
On Sun, 22 Nov 2020, Tobias Pape wrote:
On 22. Nov 2020, at 18:51, Levente Uzonyi leves@caesar.elte.hu wrote:
Hi Tobias,
On Sun, 22 Nov 2020, Tobias Pape wrote:
On 22. Nov 2020, at 17:46, Levente Uzonyi leves@caesar.elte.hu wrote: Hi All, Since most (every?) practical use of #respondsTo: is to check whether it's safe to send the message or not, I think, contrary to what was mentioned in this thread, that #respondsTo: does not have to return true when sending the message would not result in an MNU. So, I suggest adding the following implementation to expose the dynamic nature of JsonObject: JsonObject >> #respondsTo: aSymbol
| precedence | (super respondsTo: aSymbol) ifTrue: [ ^true ]. (precedence := aSymbol precedence) = 1 ifTrue: [ ^self includesKey: aSymbol ]. (precedence = 3 and: [ (aSymbol indexOf: $:) = aSymbol size ]) ifTrue: [ ^self includesKey: aSymbol allButLast ]. ^false
That's nice! but why not make it simpler?
JsonObject >> #respondsTo: aSymbol
| precedence | (super respondsTo: aSymbol) ifTrue: [ ^true ]. aSymbol isSimpleGetter ifTrue: [^self includesKey: aSymbol]. aSymbol isSimpleSetter ifTrue: [^self includesKey: aSymbol asSimpleGetter]. ^false
Three reasons:
- performance
| j s | Smalltalk garbageCollect. j := JsonObject new foo: 1; bar: 2; baz: 3; yourself. s := Symbol allSymbols. { [ s do: [ :each | ] ] bench. [ s do: [ :each | j respondsTo: each ] ] bench. [ s do: [ :each | j respondsTo2: each ] ] bench. "Your suggested implementation" } #( '1,630 per second. 613 microseconds per run. 0 % GC time.' '19 per second. 52.7 milliseconds per run. 0.09992 % GC time.' '1.18 per second. 850 milliseconds per run. 32.81709 % GC time.' )
Okay, that may not be too a realistic workload. The reason of the extreme slowdown and high GC time is rapid interning and GCing of Symbols created by #asSimpleGetter.
If you change s to a handcrafted array that avoids Symbol creation, like
s := #(yourself foo foo: bar bar: baz baz: foobar foobar: name name:)
the numbers get better but still not as good as my suggestion:
#( '4,970,000 per second. 201 nanoseconds per run. 38.02 % GC time.' '147,000 per second. 6.82 microseconds per run. 1.74 % GC time.' '92,300 per second. 10.8 microseconds per run. 1.09978 % GC time.')
I thought you'd say that. But "precedence" is one of the most obscure things around that part in the image.
- backwards compatibility
#isSimpleSetter and #isSimpleGetter are available since Squeak 5.3. I use this code in 5.1 and 5.2 images as well.
Yea, Pre 5.3 I'd have said #asMutator.
- to use the same mechanism as #doesNotUnderstand:
Have a look at that method.
Then I'd rather say change DNU too. If you're down that hole (dnu/respondsTo) anyways, I don't buy the performance argument anymore.
Not everything has to be as fast as possible.
You seem to ignore that #doesNotUnderstand: is the most often used method of JsonObject. I assume you don't use the JSON package in production images, hence you don't care about performance. I do, so I'm not willing to change the implementation of #doesNotUnderstand: in my fork of the JSON package unless performance is at least as good as it is now.
Levente
Best regards -Tobias
Levente
-Tobias
Levente On Sun, 22 Nov 2020, Thiede, Christoph wrote:
(Depending on how this discussion will end, this reparented mcz file might be relevant to prevent further merging issues.) _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Von: Thiede, Christoph Gesendet: Montag, 16. November 2020 16:22:01 An: squeak-dev Betreff: AW: [squeak-dev] I'd like to contribute to the JSON project Hi Marcel, so do you propose to remove the existing implementation of dynamic forwarding from JsonObject, too (or more precisely, pull it down into DynamicJsonObject)? If yes, I would worry about compatibility problems. If no, I do not quite understand why one should override #doesNotUnderstand: but not #respondsTo: in a class. It seems a reasonable pattern for me to override them only together. :-) Best, Christoph _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 12. November 2020 10:07:28 An: squeak-dev Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project Hi all. I am in favor of adding JsonDynamicObject (or similar) which has those extra features. I would avoid putting that stuff into JsonObject. When parsing a JSON file, the dictionary class can be configured anyway. Best, Marcel
Am 10.11.2020 10:16:50 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.de>: Hi all, > And canUnderstand: ? Or is that being too picky? > If the doesNotUnderstand: is not visible externally then who cares? Isn't the contract (o respondsTo: m) ifFalse: [self should: [o m] raise: MessageNotUnderstood]], or respondsTo: not implies MNU ?
Well, my conception of the general contract would be exactly the following: (o class canUnderstand: m) ifTrue: [ self assert: [o respondsTo: m]]. (o respondsTo: m) ifFalse: [ self deny: [o class canUnderstand: m]]. (o respondsTo: m) ifTrue: [ self shouldnt: [o m] raise: MessageNotUnderstood]. [o m] on: MessageNotUnderstood do: [ self deny: [o respondsTo: m]]. But I would *not* require the other direction of the implication - for #canUnderstand:, this is simply not possible for dynamic forwarding (unless we make false promises on the class side), and in my opinion, the current discussion shows that the same argument applies for the second statement, too.
I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?
IMHO, this goes beyond syntactic sugar. :-) As I tried to explain below, a proper implementation of #respondsTo: could be an essential prerequisite for using JsonObjects polymorphically with first-class object instances. In my use case, this is a crucial feature and if my proposal is discarded, I will have to subclass JsonObject ... Best, Christoph _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 10. November 2020 09:34:49 An: squeak-dev Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project > and generate the getter setter on demand (via doesNotUnderstand:) That's what I opted for, too, in: https://github.com/hpi-swa/MessageSendRecorder 's MessageSendRecordExtension. Best. Marcel
Am 10.11.2020 09:32:07 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>: Hi all,
for importing Matlab struct, I create classes on the fly and generate the getter setter on demand (via doesNotUnderstand:) See MatFileReader package in http://www.squeaksource.com/STEM.html Le mar. 10 nov. 2020 à 09:06, Marcel Taeumel marcel.taeumel@hpi.de a écrit : > And canUnderstand: ? Or is that being too picky? Ah, right. On the class level, it would be like Levente inferred from my suggestion. I only thought of #respondsTo: to answer "true" only for the simple setter/getters that have keys present in the actual dictionary instance. Hmmm..... I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right? Best, Marcel
Am 09.11.2020 21:08:14 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
On Sun, Nov 8, 2020 at 11:04 PM Marcel Taeumel marcel.taeumel@hpi.de wrote: Hi Levente. Sounds right. If an object can answer to some extra messages via #doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash. And canUnderstand: ? Or is that being too picky? I did not know about #dictionaryClass:. That's a powerful hook. Best, Marcel
Am 09.11.2020 03:07:54 schrieb Levente Uzonyi <leves@caesar.elte.hu>: Hi Christoph, On Sun, 8 Nov 2020, Christoph Thiede wrote: > Hi Levente, > > would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be > great because I depend on this functionality in another project and > currently require your JSON fork in my baseline. :-) I cannot merge it because that would bring back long removed methods, and MC wouldn't allow me to reject those. But I can add the changes manually. If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:. What is the purpose of that method? I'm asking because it has got no comment, so I'm not sure its implementation is correct. For example, should JsonObject new respondsTo: #foo: return false? What should the following return? JsonObject new foo: 1; respondsTo: #foo: Another question is whether it is generally useful or not? If it's not, you can still have the desired behavior by creating a subclass. E.g.: JsonObject subclass: #PseudoObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'PseudoObject' PseudoObject >> respondsTo: aSymbol ^ (super respondsTo: aSymbol) or: [self includesKey: aSymbol] (Json new dictionaryClass: PseudoObject; readFrom: '{"foo": 42}' readStream) respondsTo: #foo "==> true" Levente > > Best, > Christoph > > > > -- > Sent from: http://forum.world.st/Squeak-Dev-f45488.html
-- _,,,^..^,,,_ best, Eliot
On 22. Nov 2020, at 19:37, Levente Uzonyi leves@caesar.elte.hu wrote:
Hi Tobias,
On Sun, 22 Nov 2020, Tobias Pape wrote:
On 22. Nov 2020, at 18:51, Levente Uzonyi leves@caesar.elte.hu wrote: Hi Tobias, On Sun, 22 Nov 2020, Tobias Pape wrote:
On 22. Nov 2020, at 17:46, Levente Uzonyi leves@caesar.elte.hu wrote: Hi All, Since most (every?) practical use of #respondsTo: is to check whether it's safe to send the message or not, I think, contrary to what was mentioned in this thread, that #respondsTo: does not have to return true when sending the message would not result in an MNU. So, I suggest adding the following implementation to expose the dynamic nature of JsonObject: JsonObject >> #respondsTo: aSymbol
| precedence | (super respondsTo: aSymbol) ifTrue: [ ^true ]. (precedence := aSymbol precedence) = 1 ifTrue: [ ^self includesKey: aSymbol ]. (precedence = 3 and: [ (aSymbol indexOf: $:) = aSymbol size ]) ifTrue: [ ^self includesKey: aSymbol allButLast ]. ^false
That's nice! but why not make it simpler? JsonObject >> #respondsTo: aSymbol
| precedence | (super respondsTo: aSymbol) ifTrue: [ ^true ]. aSymbol isSimpleGetter ifTrue: [^self includesKey: aSymbol]. aSymbol isSimpleSetter ifTrue: [^self includesKey: aSymbol asSimpleGetter]. ^false
Three reasons:
- performance
| j s | Smalltalk garbageCollect. j := JsonObject new foo: 1; bar: 2; baz: 3; yourself. s := Symbol allSymbols. { [ s do: [ :each | ] ] bench. [ s do: [ :each | j respondsTo: each ] ] bench. [ s do: [ :each | j respondsTo2: each ] ] bench. "Your suggested implementation" } #( '1,630 per second. 613 microseconds per run. 0 % GC time.' '19 per second. 52.7 milliseconds per run. 0.09992 % GC time.' '1.18 per second. 850 milliseconds per run. 32.81709 % GC time.' ) Okay, that may not be too a realistic workload. The reason of the extreme slowdown and high GC time is rapid interning and GCing of Symbols created by #asSimpleGetter. If you change s to a handcrafted array that avoids Symbol creation, like s := #(yourself foo foo: bar bar: baz baz: foobar foobar: name name:) the numbers get better but still not as good as my suggestion: #( '4,970,000 per second. 201 nanoseconds per run. 38.02 % GC time.' '147,000 per second. 6.82 microseconds per run. 1.74 % GC time.' '92,300 per second. 10.8 microseconds per run. 1.09978 % GC time.')
I thought you'd say that. But "precedence" is one of the most obscure things around that part in the image.
- backwards compatibility
#isSimpleSetter and #isSimpleGetter are available since Squeak 5.3. I use this code in 5.1 and 5.2 images as well.
Yea, Pre 5.3 I'd have said #asMutator.
- to use the same mechanism as #doesNotUnderstand:
Have a look at that method.
Then I'd rather say change DNU too. If you're down that hole (dnu/respondsTo) anyways, I don't buy the performance argument anymore.
Not everything has to be as fast as possible.
You seem to ignore that #doesNotUnderstand: is the most often used method of JsonObject. I assume you don't use the JSON package in production images, hence you don't care about performance.
I do. It never has been the bottleneck.
I do, so I'm not willing to change the implementation of #doesNotUnderstand: in my fork of the JSON package unless performance is at least as good as it is now.
I just want the image to remain tractable. Performance is nice. But if you rely on performance with the JSOn stuff, subclass the JsonObject and implement your keys as messages? That ought to be the fastest way, no? I though it was meant to be that way.
That said, I rarely remain in the JSON space for longer than necessary; I'd rather have proper objects and only convert on "the edges"
I'm not against fast things. I'm merely a bit startled by fast things that are harder to understand than necessary…
Best regards -Tobias
PS: Levente, your code is almost always the fastest variant of anything we discuss on here. That's amazing in itself. Don't get the impression I'm not amazed by that ;)
Levente
Best regards -Tobias
Levente
-Tobias
Levente On Sun, 22 Nov 2020, Thiede, Christoph wrote:
On Sun, 22 Nov 2020, Tobias Pape wrote:
On 22. Nov 2020, at 19:37, Levente Uzonyi leves@caesar.elte.hu wrote:
Hi Tobias,
On Sun, 22 Nov 2020, Tobias Pape wrote:
On 22. Nov 2020, at 18:51, Levente Uzonyi leves@caesar.elte.hu wrote: Hi Tobias, On Sun, 22 Nov 2020, Tobias Pape wrote:
On 22. Nov 2020, at 17:46, Levente Uzonyi leves@caesar.elte.hu wrote: Hi All, Since most (every?) practical use of #respondsTo: is to check whether it's safe to send the message or not, I think, contrary to what was mentioned in this thread, that #respondsTo: does not have to return true when sending the message would not result in an MNU. So, I suggest adding the following implementation to expose the dynamic nature of JsonObject: JsonObject >> #respondsTo: aSymbol
| precedence | (super respondsTo: aSymbol) ifTrue: [ ^true ]. (precedence := aSymbol precedence) = 1 ifTrue: [ ^self includesKey: aSymbol ]. (precedence = 3 and: [ (aSymbol indexOf: $:) = aSymbol size ]) ifTrue: [ ^self includesKey: aSymbol allButLast ]. ^false
That's nice! but why not make it simpler? JsonObject >> #respondsTo: aSymbol
| precedence | (super respondsTo: aSymbol) ifTrue: [ ^true ]. aSymbol isSimpleGetter ifTrue: [^self includesKey: aSymbol]. aSymbol isSimpleSetter ifTrue: [^self includesKey: aSymbol asSimpleGetter]. ^false
Three reasons:
- performance
| j s | Smalltalk garbageCollect. j := JsonObject new foo: 1; bar: 2; baz: 3; yourself. s := Symbol allSymbols. { [ s do: [ :each | ] ] bench. [ s do: [ :each | j respondsTo: each ] ] bench. [ s do: [ :each | j respondsTo2: each ] ] bench. "Your suggested implementation" } #( '1,630 per second. 613 microseconds per run. 0 % GC time.' '19 per second. 52.7 milliseconds per run. 0.09992 % GC time.' '1.18 per second. 850 milliseconds per run. 32.81709 % GC time.' ) Okay, that may not be too a realistic workload. The reason of the extreme slowdown and high GC time is rapid interning and GCing of Symbols created by #asSimpleGetter. If you change s to a handcrafted array that avoids Symbol creation, like s := #(yourself foo foo: bar bar: baz baz: foobar foobar: name name:) the numbers get better but still not as good as my suggestion: #( '4,970,000 per second. 201 nanoseconds per run. 38.02 % GC time.' '147,000 per second. 6.82 microseconds per run. 1.74 % GC time.' '92,300 per second. 10.8 microseconds per run. 1.09978 % GC time.')
I thought you'd say that. But "precedence" is one of the most obscure things around that part in the image.
- backwards compatibility
#isSimpleSetter and #isSimpleGetter are available since Squeak 5.3. I use this code in 5.1 and 5.2 images as well.
Yea, Pre 5.3 I'd have said #asMutator.
- to use the same mechanism as #doesNotUnderstand:
Have a look at that method.
Then I'd rather say change DNU too. If you're down that hole (dnu/respondsTo) anyways, I don't buy the performance argument anymore.
Not everything has to be as fast as possible.
You seem to ignore that #doesNotUnderstand: is the most often used method of JsonObject. I assume you don't use the JSON package in production images, hence you don't care about performance.
I do. It never has been the bottleneck.
I do, so I'm not willing to change the implementation of #doesNotUnderstand: in my fork of the JSON package unless performance is at least as good as it is now.
I just want the image to remain tractable.
Does having a method or two implemented in an external package affect that? Also, have you ever had a look at how other stuff is implemented in that package?
Performance is nice. But if you rely on performance with the JSOn stuff, subclass the JsonObject and implement your keys as messages? That ought to be the fastest way, no?
It depends on how your JsonObjects are created. If you parse a json from an external source, you can't do that unless you hardcode the structure of the json into your application.
I though it was meant to be that way.
That said, I rarely remain in the JSON space for longer than necessary; I'd rather have proper objects and only convert on "the edges"
See above.
Levente
I'm not against fast things. I'm merely a bit startled by fast things that are harder to understand than necessary…
Best regards -Tobias
PS: Levente, your code is almost always the fastest variant of anything we discuss on here. That's amazing in itself. Don't get the impression I'm not amazed by that ;)
Levente
Best regards -Tobias
Levente
-Tobias
Levente On Sun, 22 Nov 2020, Thiede, Christoph wrote:
On 23. Nov 2020, at 18:08, Levente Uzonyi leves@caesar.elte.hu wrote:
On Sun, 22 Nov 2020, Tobias Pape wrote:
On 22. Nov 2020, at 19:37, Levente Uzonyi leves@caesar.elte.hu wrote: Hi Tobias, On Sun, 22 Nov 2020, Tobias Pape wrote:
On 22. Nov 2020, at 18:51, Levente Uzonyi leves@caesar.elte.hu wrote: Hi Tobias, On Sun, 22 Nov 2020, Tobias Pape wrote: Three reasons:
- performance
| j s | Smalltalk garbageCollect. j := JsonObject new foo: 1; bar: 2; baz: 3; yourself. s := Symbol allSymbols. { [ s do: [ :each | ] ] bench. [ s do: [ :each | j respondsTo: each ] ] bench. [ s do: [ :each | j respondsTo2: each ] ] bench. "Your suggested implementation" } #( '1,630 per second. 613 microseconds per run. 0 % GC time.' '19 per second. 52.7 milliseconds per run. 0.09992 % GC time.' '1.18 per second. 850 milliseconds per run. 32.81709 % GC time.' ) Okay, that may not be too a realistic workload. The reason of the extreme slowdown and high GC time is rapid interning and GCing of Symbols created by #asSimpleGetter. If you change s to a handcrafted array that avoids Symbol creation, like s := #(yourself foo foo: bar bar: baz baz: foobar foobar: name name:) the numbers get better but still not as good as my suggestion: #( '4,970,000 per second. 201 nanoseconds per run. 38.02 % GC time.' '147,000 per second. 6.82 microseconds per run. 1.74 % GC time.' '92,300 per second. 10.8 microseconds per run. 1.09978 % GC time.')
I thought you'd say that. But "precedence" is one of the most obscure things around that part in the image.
- backwards compatibility
#isSimpleSetter and #isSimpleGetter are available since Squeak 5.3. I use this code in 5.1 and 5.2 images as well.
Yea, Pre 5.3 I'd have said #asMutator.
- to use the same mechanism as #doesNotUnderstand:
Have a look at that method.
Then I'd rather say change DNU too. If you're down that hole (dnu/respondsTo) anyways, I don't buy the performance argument anymore. Not everything has to be as fast as possible.
You seem to ignore that #doesNotUnderstand: is the most often used method of JsonObject. I assume you don't use the JSON package in production images, hence you don't care about performance.
I do. It never has been the bottleneck.
I do, so I'm not willing to change the implementation of #doesNotUnderstand: in my fork of the JSON package unless performance is at least as good as it is now.
I just want the image to remain tractable.
Does having a method or two implemented in an external package affect that? Also, have you ever had a look at how other stuff is implemented in that package?
Been a while. I've used it for some years now but lately, I've not looked into the implementation anymore, no.
Performance is nice. But if you rely on performance with the JSOn stuff, subclass the JsonObject and implement your keys as messages? That ought to be the fastest way, no?
It depends on how your JsonObjects are created. If you parse a json from an external source, you can't do that unless you hardcode the structure of the json into your application.
Yes, exactly.
I though it was meant to be that way.
That said, I rarely remain in the JSON space for longer than necessary; I'd rather have proper objects and only convert on "the edges"
See above.
Best regards -Tobias
Levente
I'm not against fast things. I'm merely a bit startled by fast things that are harder to understand than necessary…
Best regards -Tobias
PS: Levente, your code is almost always the fastest variant of anything we discuss on here. That's amazing in itself. Don't get the impression I'm not amazed by that ;)
Levente
Best regards -Tobias
Levente
Hi Christoph,
Your code looks correct to me, though it's a bit too slow for my taste. I've fixed it in my fork of JSON[1] as well.
Levente [1] http://squeaksource.com/PostgresV3/JSON-ul.55.mcz
On Sat, 5 Sep 2020, Thiede, Christoph wrote:
Hi all,
I'd like to contribute to the JSON project, but apparently I lack the required access rights. Would it be possible to review this patch, which adds UTF-16 support for JSON strings, with the final goal to introduce it into the repository? :-)
Best,
Christoph
Hi Levente,
is there no active development happening on http://www.squeaksource.com/JSON any longer? Is your fork specialized for optimized code? I was rather trying to reuse existing functionality such as #nextHexDigit. Just for interest, how much faster did you get the code by optimizing my changes? ;-)
Best,
Christoph
http://www.hpi.de/ ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu Gesendet: Sonntag, 6. September 2020 02:13:56 An: The general-purpose Squeak developers list Cc: Niephaus, Fabio Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project
Hi Christoph,
Your code looks correct to me, though it's a bit too slow for my taste. I've fixed it in my fork of JSON[1] as well.
Levente [1] http://squeaksource.com/PostgresV3/JSON-ul.55.mcz
On Sat, 5 Sep 2020, Thiede, Christoph wrote:
Hi all,
I'd like to contribute to the JSON project, but apparently I lack the required access rights. Would it be possible to review this patch, which adds UTF-16 support for JSON strings, with the final goal to introduce it into the repository? :-)
Best,
Christoph
Hi
Tony could add you ..
Best regards -Tobias
On 08.09.2020, at 10:42, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:
Hi Levente,
is there no active development happening on http://www.squeaksource.com/JSON any longer? Is your fork specialized for optimized code? I was rather trying to reuse existing functionality such as #nextHexDigit. Just for interest, how much faster did you get the code by optimizing my changes? ;-)
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu Gesendet: Sonntag, 6. September 2020 02:13:56 An: The general-purpose Squeak developers list Cc: Niephaus, Fabio Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project
Hi Christoph,
Your code looks correct to me, though it's a bit too slow for my taste. I've fixed it in my fork of JSON[1] as well.
Levente [1] http://squeaksource.com/PostgresV3/JSON-ul.55.mcz
On Sat, 5 Sep 2020, Thiede, Christoph wrote:
Hi all,
I'd like to contribute to the JSON project, but apparently I lack the required access rights. Would it be possible to review this patch, which adds UTF-16 support for JSON strings, with the final goal to introduce it into the repository? :-)
Best,
Christoph
On 2020-09-08, at 9:30 AM, Tobias Pape Das.Linux@gmx.de wrote:
Hi
Tony could add you ..
For a fairly widely used facility like this it would be nice to gather all the best bits into one well maintained place. I use the 'raw' version with my Weatherstation and Levente's version in the postgres package for a work thing... nice to have just one.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim All new: The software is not compatible with previous versions.
Without wanting to step on anyone's toes, +1 for centralizing packages like this. If Levente hadn't explained in his email that his repository is a fork, I would not even have known which version to develop against. Such things are confusing and impede open source contributions.
Are you talking about integrating it into the Trunk or would this be another step?
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von tim Rowledge tim@rowledge.org Gesendet: Dienstag, 8. September 2020 21:00:03 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project
On 2020-09-08, at 9:30 AM, Tobias Pape Das.Linux@gmx.de wrote:
Hi
Tony could add you ..
For a fairly widely used facility like this it would be nice to gather all the best bits into one well maintained place. I use the 'raw' version with my Weatherstation and Levente's version in the postgres package for a work thing... nice to have just one.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim All new: The software is not compatible with previous versions.
Hi Christoph,
On Tue, 8 Sep 2020, Thiede, Christoph wrote:
Hi Levente,
is there no active development happening on http://www.squeaksource.com/JSON%C2%A0any longer?
Last commit is from 2016. I wanted to have our changes added to the main repository[1].
Is your fork specialized for optimized code?
It has got performance improvements and new features as well. There are quite a few changes, so I suggest you go through the MC history if you want to know what has been changed.
I was rather trying to reuse existing functionality such as #nextHexDigit. Just for interest, how much faster did you get the code by optimizing my changes? ;-)
I haven't measured it. The parser has been rewritten, so the code is quite different. But I expect my version to be at least a magnitude faster.
Levente
[1] http://forum.world.st/Another-version-of-JSON-in-the-Inbox-td5066614.html
Best,
Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu Gesendet: Sonntag, 6. September 2020 02:13:56 An: The general-purpose Squeak developers list Cc: Niephaus, Fabio Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project Hi Christoph,
Your code looks correct to me, though it's a bit too slow for my taste. I've fixed it in my fork of JSON[1] as well.
Levente [1] http://squeaksource.com/PostgresV3/JSON-ul.55.mcz
On Sat, 5 Sep 2020, Thiede, Christoph wrote:
Hi all,
I'd like to contribute to the JSON project, but apparently I lack the required access rights. Would it be possible to review this patch, which adds UTF-16 support for JSON strings, with the final goal to introduce it into
the
repository? :-)
Best,
Christoph
Hi all, hi Levente,
I just wanted to send you a fix for parsing "\u2139\ufffd", but then I realized that you already had fixed this in the repository. So what, at least I understood my own error!
However, is there an option to subscribe to arbitrary packages (such as the JSON package) in order to get notified via email about new changes to it? :-)
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu Gesendet: Dienstag, 8. September 2020 22:22:10 An: The general-purpose Squeak developers list Cc: Niephaus, Fabio Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project
Hi Christoph,
On Tue, 8 Sep 2020, Thiede, Christoph wrote:
Hi Levente,
is there no active development happening on http://www.squeaksource.com/JSON any longer?
Last commit is from 2016. I wanted to have our changes added to the main repository[1].
Is your fork specialized for optimized code?
It has got performance improvements and new features as well. There are quite a few changes, so I suggest you go through the MC history if you want to know what has been changed.
I was rather trying to reuse existing functionality such as #nextHexDigit. Just for interest, how much faster did you get the code by optimizing my changes? ;-)
I haven't measured it. The parser has been rewritten, so the code is quite different. But I expect my version to be at least a magnitude faster.
Levente
[1] http://forum.world.st/Another-version-of-JSON-in-the-Inbox-td5066614.html
Best,
Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu Gesendet: Sonntag, 6. September 2020 02:13:56 An: The general-purpose Squeak developers list Cc: Niephaus, Fabio Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project Hi Christoph,
Your code looks correct to me, though it's a bit too slow for my taste. I've fixed it in my fork of JSON[1] as well.
Levente [1] http://squeaksource.com/PostgresV3/JSON-ul.55.mcz
On Sat, 5 Sep 2020, Thiede, Christoph wrote:
Hi all,
I'd like to contribute to the JSON project, but apparently I lack the required access rights. Would it be possible to review this patch, which adds UTF-16 support for JSON strings, with the final goal to introduce it into
the
repository? :-)
Best,
Christoph
Am Di., 29. Sept. 2020 um 02:37 Uhr schrieb Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de:
However, is there an option to subscribe to arbitrary packages (such as the JSON package) in order to get notified via email about new changes to it? :-)
Lately I have seen a bot that automatically posts a pull request for your npm package.json if a dependency has a new release...
Could have been https://github.com/renovatebot/renovate
Now there is probably nothing like "releases" going on in the JSON package, but maybe a similar service can be achieved for Monticello or Metacello configurations.
Hi Christoph,
On Tue, 29 Sep 2020, Thiede, Christoph wrote:
Hi all, hi Levente,
I just wanted to send you a fix for parsing "\u2139\ufffd", but then I realized that you already had fixed this in the repository. So what, at least I understood my own error!
That's really weird because we even had a small discussion about it in this thread: http://forum.world.st/I-d-like-to-contribute-to-the-JSON-project-tp5121353p5...
However, is there an option to subscribe to arbitrary packages (such as the JSON package) in order to get notified via email about new changes to it? :-)
Email? I don't think so. RSS is probably the closest thing: https://squeaksource.com/feed.rss
Levente
Best,
Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu Gesendet: Dienstag, 8. September 2020 22:22:10 An: The general-purpose Squeak developers list Cc: Niephaus, Fabio Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project Hi Christoph,
On Tue, 8 Sep 2020, Thiede, Christoph wrote:
Hi Levente,
is there no active development happening on http://www.squeaksource.com/JSON%C2%A0any longer?
Last commit is from 2016. I wanted to have our changes added to the main repository[1].
Is your fork specialized for optimized code?
It has got performance improvements and new features as well. There are quite a few changes, so I suggest you go through the MC history if you want to know what has been changed.
I was rather trying to reuse existing functionality such as #nextHexDigit. Just for interest, how much faster did you get the code by optimizing my changes? ;-)
I haven't measured it. The parser has been rewritten, so the code is quite different. But I expect my version to be at least a magnitude faster.
Levente
[1] http://forum.world.st/Another-version-of-JSON-in-the-Inbox-td5066614.html
Best,
Christoph
_
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu Gesendet: Sonntag, 6. September 2020 02:13:56 An: The general-purpose Squeak developers list Cc: Niephaus, Fabio Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project Hi Christoph,
Your code looks correct to me, though it's a bit too slow for my taste. I've fixed it in my fork of JSON[1] as well.
Levente [1] http://squeaksource.com/PostgresV3/JSON-ul.55.mcz
On Sat, 5 Sep 2020, Thiede, Christoph wrote:
Hi all,
I'd like to contribute to the JSON project, but apparently I lack the required access rights. Would it be possible to review this patch, which adds UTF-16 support for JSON strings, with the final goal to introduce it into
the
repository? :-)
Best,
Christoph
I forgot about this fork you did Levente, I should probably switch! BUT, JSON is such crucial functionality these days, what do y'all think about integrating it into the base image? I guess we have some basic functionality on WebUtils... looks pretty compact, is there more to JSON than that?
Email? I don't think so. RSS is probably the closest thing: https://squeaksource.com/feed.rss
Actually, squeaksource *does* support email notifications (it's how we're getting trunk commit notifications), but only the admin can add/remove them -- I assume because it was intended for publishing to mailing lists, so we should find a way to improve that. Still, in the meantime, an admin of the project *could* add your email, Christoph. Then, it's just a matter of whether or not squeaksource.com instance of SqueakSource is hooked up to a mail server, or not..
Hi Levente, Hi Chris,
That's really weird because we even had a small discussion about it in this thread: http://forum.world.st/I-d-like-to-contribute-to-the-JSON-project-tp5121353p5...
Of course, I'm just replying to this thread, but I did not realize before that you did not only optimize but also fix my code :)
Email? I don't think so. RSS is probably the closest thing:
http://www.hpi.de/ Ah! This looks promising! Can we have an RSS feed for every single repository? I cannot find the JSON repository in the linked feed.
BUT, JSON is such crucial functionality these days, what do y'all think about integrating it into the base image?
+1! This would also save you some work when writing Metacello baselines where at the moment, you have to specify the dependency manually ...
I guess we have some basic functionality on WebUtils... looks pretty compact, is there more to JSON than that?
Interesting, never heard of that before! JSON has some more features indeed, I guess. For example, it provides JsonObject, a subclass of Dictionary that implements dynamic forwarding to its property. I find this extremely handy when writing or prototyping REST applications because you can use these objects polymorphic with a custom class instance! Also, WebUtils do not support some special JSON constructs such as certain string escapes such as \f or UTF-16 char codes (see the start of this thread).
Still, in the meantime, an admin of the project could add your email, Christoph. Then, it's just a matter of whether or not squeaksource.com instance of SqueakSource is hooked up to a mail server, or not..
No need for special treatment :) It would be great to subscribe to emails for every single project, but how expensive would that be? RSS sounds easier to me (as it's already implemented in some way), there are external services that can email you about RSS news. Where are the sources for it, is it SqueakSource, SqueakSource 2, or SqueakSource 3?
Best, Christoph ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Chris Muller asqueaker@gmail.com Gesendet: Mittwoch, 30. September 2020 00:25:17 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project
I forgot about this fork you did Levente, I should probably switch! BUT, JSON is such crucial functionality these days, what do y'all think about integrating it into the base image? I guess we have some basic functionality on WebUtils... looks pretty compact, is there more to JSON than that?
Email? I don't think so. RSS is probably the closest thing: https://squeaksource.com/feed.rss
Actually, squeaksource does support email notifications (it's how we're getting trunk commit notifications), but only the admin can add/remove them -- I assume because it was intended for publishing to mailing lists, so we should find a way to improve that. Still, in the meantime, an admin of the project could add your email, Christoph. Then, it's just a matter of whether or not squeaksource.comhttp://squeaksource.com instance of SqueakSource is hooked up to a mail server, or not..
squeak-dev@lists.squeakfoundation.org