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

Levente Uzonyi leves at caesar.elte.hu
Sun Nov 22 16:46:21 UTC 2020


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


More information about the Squeak-dev mailing list