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

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Mon Nov 9 16:29:01 UTC 2020


> 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 at lists.squeakfoundation.org> im Auftrag von Levente Uzonyi <leves at 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 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
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



>
>
>

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


More information about the Squeak-dev mailing list