But the engine could find transforms to apply when...

# minutest

[natpryce]

But the engine could find transforms to apply when it scans the classpath

[natpryce]

Starting to sound like we need some category theory…

[dmcg]

But I'm pleased that I've fired your enthusiasm for the concept

[dmcg]

if not some of the execution details

[natpryce]

Instead of a map, why not a list of objects, that can be queried with filterIsInstance?

[natpryce]

It is also a closer fit to Java and Kotlin’s model of annotations

[dmcg]

That was my other option.

[dmcg]

It might be better TBH

[dmcg]

The map is more friendly for arbitrary stuff - the annotations model only came to me as I was building the filters

[dmcg]

and I could implement that in terms of the map, but less reasonably vv

[natpryce]

The trouble with map is that one ends up assuming that a name maps to a specific type of value, and then you get runtime exceptions. A map-of-typed-keys avoids this by having keys with instance-identity that enforce the same type goes in and out (and defining a default value). A list of objects also avoids it by forcing you to search for an annotation of a specific type, but you don’t get the convenience of a predefined default value.

[dmcg]

There's the efficiency of lookup (and storage) to consider too.

[dmcg]

For example, FOCUS.appliesTo(properties) is evaluated a lot if there is any focused node - that will be quick if there are a lot of mapped properties, slow if there is a long list

[dmcg]

but, I guess that few annotations will be the default

[dmcg]

and a linear search in a list even with instanceOf may be better than a HashMap

[dmcg]

Your platform may vary

[dmcg]

Space / time performance notwithstanding I picked Map<Any, Any> because I can build pretty much anything with that, and offer nicer abstractions on top

[dmcg]

The problem is that Map<Any, Any> is in the public interface

[dmcg]

I could make that internal while we wrangle

[natpryce]

I could put together a typed map abstraction, for your perusal. Or, I think we could implement the wrapper approach with the same Annotation API

[natpryce]

It would be nice for annotations to have the same syntactic sugar for top level contexts

[dmcg]

I have made that work, but the type inference doesn’t make it smooth

[dmcg]

It isn't required for include and exclude (trying them on for size), but maybe would be for eg tagging

[dmcg]

I could make it work nicely if we specified the filters elsewhere in JupiterTests