Re: Static typing question

> No, it doesn't. As I mentioned, I have _nested_ objects, and `Map<String,
Object>` only gets you one level deep. I need `json.data.type` (which is a
String) and `json.data[0].relationships['author'].id` and all sorts of
combinations thereof.

That was a quick (naive)answer. I agree that it needs something better.
However, python has you covered in the same way.

On Thu, Jan 4, 2024 at 9:11 PM Christopher Smith <[email protected]> wrote:

> > For the REST thing, mapping JSON to a Dict[str, Any] in Python does what
> you say too
>
> No, it doesn't. As I mentioned, I have _nested_ objects, and `Map<String,
> Object>` only gets you one level deep. I need `json.data.type` (which is a
> String) and `json.data[0].relationships['author'].id` and all sorts of
> combinations thereof.
>
> On Sat, Dec 30, 2023 at 10:40 PM Agile Developer <[email protected]>
> wrote:
>
>>  Hi, Christopher,
>>
>> Spock/Geb are my go-to for testing. I actually used spock to integration
>> test Python services. But still I think they can exist within a typed
>> universe.
>>
>> For the REST thing, mapping JSON to a Dict[str, Any] in Python does what
>> you say too and mypy is happy. For Groovy I did something similar.
>>
>> Can you give me an example for (1)?
>>
>> What I find difficult is the metaclass where you can intercept calls (non
>> existing) and handle them.
>>
>> This is not reflected in an interface and it is definitely not
>> self-documenting. An example is here
>>
>> Object.class.metaClass.explode{-> println "Boom! ${delegate} Exploded!"}
>>>
>>>
>> so now String objects gain explosive powers. But it is not obvious if
>> there is no documentation. This is a non-discoverable feature.
>>
>> But the idea here is that this is a ExplosionMixin<T>, implements
>> Mixin<T> so instead of writing
>>
>> "SomeString".explode();
>>>
>>>
>> you can write something like
>>
>> mix("SomeString",  ExplosionMixin).explode() or ExplosionMixin.mix(
>>> "SomeString").explode()
>>
>>
>> and have self-documentation and auto-completion.
>>
>>
>>
>> On Sat, Dec 30, 2023 at 8:57 PM Christopher Smith <
>> [email protected]> wrote:
>>
>>> I typically use Groovy in its static mode, and the single biggest value
>>> to me is the AST-transformation system. However, there are cases where I
>>> find dynamic mode very useful.
>>>
>>> 1. Methods that handle processing for particular subtypes of a base
>>> type. I could do something like a class-based map with, and I do in cases
>>> where I need pluggability, but for the case of "I have these 4 types of
>>> incoming message and need to convert them to a target format", using
>>> dynamic dispatch on a top-level method results in much clearer code than a
>>> giant switch or hand-written reflection.
>>>
>>> 2. Quick-and-dirty processing of data structures. REST calls usually
>>> return JSON these days, and if I know that I just to pull some simple data
>>> out of a nested structure, it's much easier to use dynamic mode against a
>>> Map than to try to write a bunch of mapping classes.
>>>
>>> 3. Spock and Geb. I have managed to convince consulting clients that
>>> stick to plain Java only for the business code to adopt Spock for testing
>>> because it's so powerful and clear. Spock is the Groovy equivalent of an
>>> IOCCC winner, and it showcases the dramatic lengths you can (and nearly all
>>> of us shouldn't) go to.
>>>
>>> On Sat, Dec 30, 2023 at 12:17 PM Agile Developer <[email protected]>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I was a  4 years user of Grails/Groovy (last year mostly Python). With
>>>> the general trend of people moving to static languages, is there any reason
>>>> that Groovy needs to stay dynamic?
>>>>
>>>> I see Python having the mypy approach, I see gradle moving to Kotlin
>>>> and FE mostly on Typescript.
>>>>
>>>> I understand that the @CompileStatic is the supported method, but
>>>> having true static typing (with the Script-Like enhancements other
>>>> Languages added, would be beneficial).
>>>>
>>>> Is there still a reason to keep it dynamic? What is the benefit?
>>>>
>>>> --
>>>> Dr. Vasileios Anagnostopoulos (MSc,PhD)
>>>> Researcher/Developer
>>>>
>>>
>>
>> --
>> Dr. Vasileios Anagnostopoulos (MSc,PhD)
>> Researcher/Developer
>>
>
>
> --
> Christopher Smith
>


-- 
Dr. Vasileios Anagnostopoulos (MSc,PhD)
Researcher/Developer