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

Sun Nov 22 17:08:43 UTC 2020

+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 at lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux at 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 at 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 at 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 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 ...
>> Best,
>> Christoph
>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________
>> 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 's MessageSendRecordExtension.
>> Best.
>> Marcel
>>
>>      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
>> Le mar. 10 nov. 2020 à 09:06, Marcel Taeumel <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?
>> Best,
>> Marcel
>>
>>      Am 09.11.2020 21:08:14 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>> On Sun, Nov 8, 2020 at 11:04 PM Marcel Taeumel <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.
>> 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
>> --
>> _,,,^..^,,,_
>> best, Eliot
>

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