[squeak-dev] I'd like to contribute to the JSON project
Tobias Pape
Das.Linux at gmx.de
Sun Nov 22 17:03:35 UTC 2020
> 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
>
More information about the Squeak-dev
mailing list
|