Hi Levente,
On 2024. 02. 24. 7:21, commits@source.squeak.org wrote:
Chris Muller uploaded a new version of JSON to project The Trunk: http://source.squeak.org/trunk/JSON-cmm.62.mcz
==================== Summary ====================
Name: JSON-cmm.62 Author: cmm Time: 24 February 2024, 1:21:44.121899 am UUID: 8a043f53-c158-4a2a-b29a-0fb20d53d6a9 Ancestors: JSON-cmm.61
- Prefix json extension methods to indicate they're intended for Json
outputs.
- Better comments, implementations and tests for new path accessing
functions.
That's a bit better, though I still don't think a Bitset, Matrix or a Heap should understand any of those methods.
Would you like #jsonPrintOn: removed for the same reason? There's also the matter of Object>>#asJsonString, and many many other examples of methods which are specific to some-but-not-all subclasses, being implemented in a common superclass which the applicable ones do inherit from.
I strongly prefer delegation of responsibility over utility methods, which are often not discovered because people aren't looking for them on various class-sides. I prefer instead to delete behaviors with #shouldNotImplement. I support if you wish to use that on methods on various subclasses to delete unwanted behaviors.
I suggested something like the following to resolve that:
Json atPath: #('foo' 1) of: aJsonObjectinstead of
aJsonObject atPath: #('foo' 1)What do you think?
- Fix and a test an Array of Associations to be a Json object.
That is not a fix but a brand new feature. What is your use case for that?
It's both. Because I'd Squeak to have the elegance of writing:
{'a' -> 1. 'b' -> { 'foo' -> 3. 'bar' -> 4 } }
to create a Json object with code, instead of being required to remember and write out its internal Smalltalk representation (which has nothing to do with the Json spec), over and over again, as in:
{'a' -> 1. 'b' -> { 'foo' -> 3. 'bar' -> 4 } as: OrderedDictionary } as: OrderedDictionary
Best, Chris