https://kotlinlang.org logo
#minutest
Title
# minutest
n

natpryce

11/27/2018, 9:16 AM
But the engine could find transforms to apply when it scans the classpath
Starting to sound like we need some category theory…
d

dmcg

11/27/2018, 3:24 PM
But I'm pleased that I've fired your enthusiasm for the concept
if not some of the execution details
n

natpryce

11/27/2018, 3:47 PM
Instead of a map, why not a list of objects, that can be queried with
filterIsInstance
?
It is also a closer fit to Java and Kotlin’s model of annotations
d

dmcg

11/27/2018, 3:48 PM
That was my other option.
It might be better TBH
The map is more friendly for arbitrary stuff - the annotations model only came to me as I was building the filters
and I could implement that in terms of the map, but less reasonably vv
n

natpryce

11/27/2018, 4:12 PM
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.
d

dmcg

11/27/2018, 9:13 PM
There's the efficiency of lookup (and storage) to consider too.
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
but, I guess that few annotations will be the default
and a linear search in a list even with instanceOf may be better than a HashMap
Your platform may vary
Space / time performance notwithstanding I picked Map<Any, Any> because I can build pretty much anything with that, and offer nicer abstractions on top
The problem is that Map<Any, Any> is in the public interface
I could make that internal while we wrangle
n

natpryce

11/28/2018, 8:19 AM
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
It would be nice for annotations to have the same syntactic sugar for top level contexts
d

dmcg

11/28/2018, 8:32 AM
I have made that work, but the type inference doesn’t make it smooth
It isn't required for include and exclude (trying them on for size), but maybe would be for eg tagging
I could make it work nicely if we specified the filters elsewhere in JupiterTests
4 Views