<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>+1 for Levente's implementation proposal, and +1 for Tobias's refactoring proposal (it might be a few byte steps longer, but readability first ;-)).</p>
<p><br>
</p>
<p>Best,</p>
<p>Christoph</p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">
<div class="x__rp_U4 x_ms-font-weight-regular x_ms-font-color-neutralDark x_rpHighlightAllClass x_rpHighlightBodyClass" id="x_Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="x_divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="x_Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont">
<div><font size="3" color="black"><span style="font-size:12pt"><a href="http://www.hpi.de/" target="_blank" rel="noopener noreferrer" id="LPNoLP"><font size="2"><span id="LPlnk909538"><font color="#757B80"></font></span></font></a></span></font></div>
</font></div>
</div>
</font></div>
</div>
</div>
</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux@gmx.de><br>
<b>Gesendet:</b> Sonntag, 22. November 2020 18:03:35<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] I'd like to contribute to the JSON project</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
<br>
> On 22. Nov 2020, at 17:46, Levente Uzonyi <leves@caesar.elte.hu> wrote:<br>
> <br>
> Hi All,<br>
> <br>
> 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.<br>
> So, I suggest adding the following implementation to expose the dynamic nature of JsonObject:<br>
> <br>
> JsonObject >> #respondsTo: aSymbol<br>
> <br>
> | precedence |<br>
> (super respondsTo: aSymbol) ifTrue: [ ^true ].<br>
> (precedence := aSymbol precedence) = 1 ifTrue: [<br>
> ^self includesKey: aSymbol ].<br>
> (precedence = 3 and: [ (aSymbol indexOf: $:) = aSymbol size ]) ifTrue: [<br>
> ^self includesKey: aSymbol allButLast ].<br>
> ^false<br>
<br>
That's nice! but why not make it simpler?<br>
<br>
JsonObject >> #respondsTo: aSymbol<br>
<br>
| precedence |<br>
(super respondsTo: aSymbol) ifTrue: [ ^true ].<br>
aSymbol isSimpleGetter ifTrue: [^self includesKey: aSymbol].<br>
aSymbol isSimpleSetter ifTrue: [^self includesKey: aSymbol asSimpleGetter].<br>
^false<br>
<br>
-Tobias<br>
<br>
> <br>
> <br>
> Levente<br>
> <br>
> On Sun, 22 Nov 2020, Thiede, Christoph wrote:<br>
> <br>
>> (Depending on how this discussion will end, this reparented mcz file might be relevant to prevent further merging issues.)<br>
>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________<br>
>> Von: Thiede, Christoph<br>
>> Gesendet: Montag, 16. November 2020 16:22:01<br>
>> An: squeak-dev<br>
>> Betreff: AW: [squeak-dev] I'd like to contribute to the JSON project <br>
>> Hi Marcel,<br>
>> 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<br>
>> 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. :-)<br>
>> Best,<br>
>> Christoph<br>
>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________<br>
>> Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel<br>
>> Gesendet: Donnerstag, 12. November 2020 10:07:28<br>
>> An: squeak-dev<br>
>> Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project <br>
>> Hi all.<br>
>> 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.<br>
>> Best,<br>
>> Marcel<br>
>> <br>
>> Am 10.11.2020 10:16:50 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.de>:<br>
>> <br>
>> Hi all,<br>
>> <br>
>> > And canUnderstand: ? Or is that being too picky?<br>
>> <br>
>> > 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 ?<br>
>> Well, my conception of the general contract would be exactly the following:<br>
>> (o class canUnderstand: m) ifTrue: [<br>
>> self assert: [o respondsTo: m]].<br>
>> (o respondsTo: m) ifFalse: [<br>
>> self deny: [o class canUnderstand: m]].<br>
>> (o respondsTo: m) ifTrue: [<br>
>> self shouldnt: [o m] raise: MessageNotUnderstood].<br>
>> [o m] on: MessageNotUnderstood do: [<br>
>> self deny: [o respondsTo: m]].<br>
>> 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<br>
>> current discussion shows that the same argument applies for the second statement, too.<br>
>> > I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?<br>
>> 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<br>
>> instances. In my use case, this is a crucial feature and if my proposal is discarded, I will have to subclass JsonObject ...<br>
>> Best,<br>
>> Christoph<br>
>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________<br>
>> Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel<br>
>> Gesendet: Dienstag, 10. November 2020 09:34:49<br>
>> An: squeak-dev<br>
>> Betreff: Re: [squeak-dev] I'd like to contribute to the JSON project <br>
>> > and generate the getter setter on demand (via doesNotUnderstand:)<br>
>> That's what I opted for, too, in: <a href="https://github.com/hpi-swa/MessageSendRecorder">
https://github.com/hpi-swa/MessageSendRecorder</a> 's MessageSendRecordExtension.<br>
>> Best.<br>
>> Marcel<br>
>> <br>
>> Am 10.11.2020 09:32:07 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:<br>
>> <br>
>> Hi all,<br>
>> for importing Matlab struct, I create classes on the fly and generate the getter setter on demand (via doesNotUnderstand:)<br>
>> See MatFileReader package in <a href="http://www.squeaksource.com/STEM.html">http://www.squeaksource.com/STEM.html</a><br>
>> Le mar. 10 nov. 2020 à 09:06, Marcel Taeumel <marcel.taeumel@hpi.de> a écrit :<br>
>> > And canUnderstand: ? Or is that being too picky?<br>
>> 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<br>
>> dictionary instance. Hmmm.....<br>
>> I would like to keep the JSON library as simple as possible. Wer are just talking about syntactic sugar here, right?<br>
>> Best,<br>
>> Marcel<br>
>> <br>
>> Am 09.11.2020 21:08:14 schrieb Eliot Miranda <eliot.miranda@gmail.com>:<br>
>> On Sun, Nov 8, 2020 at 11:04 PM Marcel Taeumel <marcel.taeumel@hpi.de> wrote:<br>
>> Hi Levente.<br>
>> Sounds right. If an object can answer to some extra messages via #doesNotUnderstand:, one should also override #respondsTo:. It is like #= and #hash.<br>
>> And canUnderstand: ? Or is that being too picky?<br>
>> I did not know about #dictionaryClass:. That's a powerful hook.<br>
>> Best,<br>
>> Marcel<br>
>> <br>
>> Am 09.11.2020 03:07:54 schrieb Levente Uzonyi <leves@caesar.elte.hu>:<br>
>> <br>
>> Hi Christoph,<br>
>> <br>
>> On Sun, 8 Nov 2020, Christoph Thiede wrote:<br>
>> <br>
>> > Hi Levente,<br>
>> ><br>
>> > would you mind to merge JSON-ct.41 (#respondsTo:) as well? This would be<br>
>> > great because I depend on this functionality in another project and<br>
>> > currently require your JSON fork in my baseline. :-)<br>
>> <br>
>> I cannot merge it because that would bring back long removed methods, and<br>
>> MC wouldn't allow me to reject those.<br>
>> But I can add the changes manually.<br>
>> If I'm not mistaken, it's just a single method JsonObject >> #respondsTo:.<br>
>> <br>
>> What is the purpose of that method?<br>
>> I'm asking because it has got no comment, so I'm not sure its<br>
>> implementation is correct.<br>
>> For example, should<br>
>> <br>
>> JsonObject new respondsTo: #foo:<br>
>> <br>
>> return false?<br>
>> What should the following return?<br>
>> <br>
>> JsonObject new<br>
>> foo: 1;<br>
>> respondsTo: #foo:<br>
>> <br>
>> Another question is whether it is generally useful or not?<br>
>> If it's not, you can still have the desired behavior by creating a<br>
>> subclass. E.g.:<br>
>> <br>
>> JsonObject subclass: #PseudoObject<br>
>> instanceVariableNames: ''<br>
>> classVariableNames: ''<br>
>> poolDictionaries: ''<br>
>> category: 'PseudoObject'<br>
>> <br>
>> PseudoObject >> respondsTo: aSymbol<br>
>> <br>
>> ^ (super respondsTo: aSymbol)<br>
>> or: [self includesKey: aSymbol]<br>
>> <br>
>> (Json new<br>
>> dictionaryClass: PseudoObject;<br>
>> readFrom: '{"foo": 42}' readStream)<br>
>> respondsTo: #foo<br>
>> "==> true"<br>
>> <br>
>> Levente<br>
>> <br>
>> ><br>
>> > Best,<br>
>> > Christoph<br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Sent from: <a href="http://forum.world.st/Squeak-Dev-f45488.html">http://forum.world.st/Squeak-Dev-f45488.html</a><br>
>> --<br>
>> _,,,^..^,,,_<br>
>> best, Eliot<br>
> <br>
<br>
<br>
<br>
</div>
</span></font>
</body>
</html>