Are scala reflection API Names or Symbols adequate for use inside transfer objects? -
introduction
i working on api written in scala. use data transfer objects (dtos) parameters passed api's functions. dtos instanciated api's user.
as api pretty abstract / generic want specify attributes of object api should operate on. example:
case class person(name: string, birthdate: date) when instance of person "p" passed api, api needs know attributes of "p" should operate on: either name or birthdate, or both of them.
so need design dto contains instance of "p" itself, kind of declaration of attributes , maybe additional information on type of "p".
string based approach
one way use strings specify attributes of "p" , maybe type. relatively simple, strings pretty lightweight , known. there formal notation of packages, types , members strings, declarations structured degree. on other side, string-declarations must validated, because user might pass invalid strings. imagine types represent attributes dedicated types instead of string, may have benefit of increased structure , maybe type designed valid instances can exist.
reflection api approach
of course reflection api came mind , experimenting declare attributes types out of reflection api. unfortunately scala 2.10.x reflection api bit unintuitive. there names, symbols, mirrors, types, typetags can cause bit of confusion.
basically see 2 alternatives attribute declaration strings:
- attribute declaration reflection api's "names"
- attribute declaration reflection api's "symbols" (especially termsymbol)
if go way, far can see, api's user, constructs dtos, have deal reflection api , names / symbols. api's implementation have make use of reflection api. there 2 places reflective code , user must have @ least little bit of knowledge of reflection api.
questions
however don't know how heavyweight these approaches are:
- are names or symbols expensive construct?
- does reflection api caching of expensive operation results or should take care that?
- are names , symbols transferable jvm via network?
- are serializable?
main question: are scala reflection api names or symbols adequate use inside transfer objects?
it seems complicated reflection api. hints welcome. , hints on other alternatives, too.
p.s.: did not include own code, yet, because api complex , reflection part in pretty experimental state. maye can deliver useful later.
1a) names easy construct , lightweight, bit more strings.
1b) symbols can't constructed user, created internally when 1 resolves names using apis staticclass or member. first calls such apis involve unpacking type signatures of symbol's owners scalasignature annotations, might costly. subsequent calls use loaded signatures, still pay cost of by-name lookup in sort of hashtable (1). declaration costs less member, because declaration doesn't base classes.
2) type signatures (e.g. lists of members of classes, params + return type of methods, etc) loaded lazily , therefore cached. mappings between java , scala reflection artifacts cached (2). best of knowledge, rest (e.g. subtyping checks) uncached few minor exceptions.
3-4) reflection artifacts depend on universe , @ moment can't serialized (3).
Comments
Post a Comment