Hello Mark
the reason was that I want them to act as if they are maps and vectors for
an end user developer and let him work with all the usual Clojure functions
for these data structures, while internally they would have some different
implementation and additional functionality (for unrelated to Clojure
itself reasons). So, for me it is less about having less API objects, it
was much more about transparency (e.g. HashMap and SortedMap have
essentially the same interface and one just uses assoc/dissoc independent
of the implementation except for the actual constructor). In my case this
works well for the "Records" as they are the elements of the "Table"
collection. But for the sequence functions operating on a "Table" - as Alex
mentioned, they return own sequences of elements ("Records") actually and
this with reason in Clojure's line of thought. And as both mentioned, this
will need restitching at the end back into a "Table". I just hoped that I
miss something and there would be a transparent way (e.g. through the
Clojure collection/sequence interfaces) to do this restitching "(into
(table) ..." without rerouting the user to custom wrappers or let him do it
on his own.
This will actually work painlessly, except that the user needs to use then
the wrapper functions, where the mapping between a records and tables map
more or less directly to maps and vectors. But if one would like to
implement something different and more involved (e.g.
column/sparse/off-heap store for the table or some indexing which is
meaningful not for a single "Record", but for the "Table" as a whole) the a
"Record" would be either only a view over specific indexes in the column
arrays (in the naive case) or the "Records" would be some derived objects
for use only by the end user, but physically detached from the actual
storage - and in these more convoluted examples (or need) the transparency
will get harder. So - it seems to me that to support both - element,
collection and sequence operations, I'll have to go so or so through some
own wrappers, which are probably less flexible than the built in functions,
but keep the whole thing consistent together (and at the end will fuse the
collection/sequence operations to maintain the "Table" abstraction).
Regards
Plamen
On Tuesday, January 15, 2019 at 6:43:09 PM UTC+1, greybird wrote:
>
> Hi Plamen, I don't have any advice to offer but I'm curious why you want
> to bind the table and column type info directly onto the result set. If you
> associate them in some other way, then you can just use plain maps and
> vectors. Are you trying to have less total objects in your API?
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
