+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-together-td5110969.html


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 at 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 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"


Levente

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201109/075e4f96/attachment.html>