[squeak-dev] I'd like to contribute to the JSON project

Marcel Taeumel marcel.taeumel at hpi.de
Thu Nov 12 09:07:28 UTC 2020

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.

Am 10.11.2020 10:16:50 schrieb Thiede, Christoph <christoph.thiede at 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 ...

Von: Squeak-dev <squeak-dev-bounces at 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] 's MessageSendRecordExtension.

Am 10.11.2020 09:32:07 schrieb Nicolas Cellier <nicolas.cellier.aka.nice at 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 at hpi.de [mailto:marcel.taeumel at 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?

Am 09.11.2020 21:08:14 schrieb Eliot Miranda <eliot.miranda at gmail.com [mailto:eliot.miranda at gmail.com]>:

On Sun, Nov 8, 2020 at 11:04 PM Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at 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.

Am 09.11.2020 03:07:54 schrieb Levente Uzonyi <leves at caesar.elte.hu [mailto:leves at 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"


> Best,
> Christoph
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html [http://forum.world.st/Squeak-Dev-f45488.html]



best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201112/ca6670e3/attachment.html>

More information about the Squeak-dev mailing list