In general, I would not rely on long term support of undocumented properties. The features that intended to be supported into the future are those that are documented.
For (1) the resolution of hsym path by indexing with a sym is not something I’ve ever seen documented. How do you believe it’s use will be beneficial over the more explicit** get .Q.dd[D;`a]** call? Is it a matter of the reduction of additional character?
For (2), the fact that get will map in a kdb database structure is documented, the following is an example on the documentation for get
q)get :mydatas p qty---------s1 p1 300s1 p2 200s1 p3 400`
I’m curious as to the usefulness of these features when compared to more explicit and readable code, at the cost of a few more characters
I know that undocumented features are generally not stable. I was hoping that I missed it in the docs or someone will say that the documentation will be updated and this is a permanent feature. :)
Indexing syntax works with monadic functions, dictionaries, even with connection handles, I don’t really see why file handles should be an exception (as it is logical). I don’t see any benefits in using .Q.dd for that particular case (other than long term support), but I will do that of couse as this feature is not meant for developers.
What is the reason for that?
I think this is very subjective. I find “get `:db/2019.12.02” more readable and elegant for mapping all tables form a given partition than, let’s say
{k!get each .Q.dd each k:key x}`:db/2019.12.02
Too bad this feature is not stable, but again, this is just my taste.