Quoting prasanth somasundar (2019-05-30 13:50:26)
> I'm hoping that I can use `elm-bytes` in a better way than being
> forced to decode it into a full Elm data type - though as I say this,
> it seems that I'd need some buy-in that I can't be guaranteed. I may
> end up with that solution in the long run, but I want to implement one
> with the double array to start and see if I can convince a few people.
I would suggest prodding Evan about this sooner rather than later. He's
definitely not going to add random access support without some
motivating use cases. Also probably useful for planning purposes to know
how receptive he is to the idea.
Arrays are definitely workable for prototyping, but if you switch over
to a flat buffer representation in the future your current design for
updates will start being O(length of segment) instead of O(log(length of
segment)), so that's something to keep in mind.
One possible design, which I think I'd do for the Haskell implementation
if I were to start from scratch: don't support in-place modifications.
Have encode and decode. This way your read support can do the obvious
thing with buffers, and your write support can be an 'Encoder' type
which is a wrapper around Bytes.Encoder + some metadata about addresses.
> Still, it's not clear to me why you'd use Cap'n Proto if you're going
> to do a full serialization/deserialization. Just use Protobufs at that
> point. You could argue that this existing for completeness is valuable
> i.e. you can run capnp on your backend and not be forced to translate
> into a protobuf on your frontend, but at that point. I'm not sure that
> this is a good enough reason to write a library like this.
Fair enough. I'd say for RPC (which you've said you're not shooting for,
so maybe moot in this case) or if you've got some existing system you
want to talk to; it would be neat to have this for writing sandstorm
apps.
> Additionally, it's not like JavaScript doesn't have more complex
> capabilities like Uint8Array that Elm could take advantage of.
Sure, but again poke Evan sooner rather than later.
> Regarding namespacing in the parallel conversation: I think it's kind
> of awful that Haskell records are accessed via functions instead of
> some scoped operator or the like. Not really useful as a comment, but I
> thought I'd add my displeasure.
+1. The Haskell implementation expects folks to use the
DuplicateRecordFields extension, which makes this a bit nicer, but yes,
records in Haskell are garbage.
> Pointer field defaults: Field defaults in general are not features I
> feel super great about. Not that I've thought about this in horribly
> great depth, but they seem to be very problematic if they are ever
> updated - your binaries will read the same bytes as two different
> structs. I always assumed that's why they were removed from proto3.
> They also don't seem *that* useful as you can handle this on the
> application layer sufficiently well. I'm curious if others think
> differently and feel strongly about their inclusion.
I definitely think they don't carry their weight in terms of
implementation cost, especially given how rarely I've seen them used in
the wild. I'll probably write that larger critique in the next week or
two; will link it to this mailing list when I do.
>
>
> getMainPhone : Struct AddressBook -> Struct PhoneNumber
> getMainPhone s =
> let s : Struct AddressBook
> in s
> |> Capnp.get .people
> |> Capnp.List.get 0 AddressBook.person
> |> Capnp.get .mainPhone AddressBook.person_phoneNumber
>
> -- assume d : Data exists. This is an `Array (Array Int)`
> -- Inputs:
>
> -- Struct
> -- { data = d
> -- , fields =
> -- -- Field AddressBook (Capnp.List.List (StructField Person))
> -- { people = ...
> -- }
> -- , viewOffset = (0, 0)
> -- , currentTraversalDistance = 0
> -- , traversalLimit = 67108864
> -- }
The salient difference in behavior here is that the traversal limit is
part of the struct, rather than the message, so if you have a branching
structure (like a tree), it can't really protect you, since it isn't
shared across branches.
I don't see an ergonomic way to address this.
>
> -- Outputs:
> -- Struct
> -- { -- Data has not been updated. Hopefully, d is not actually
> copied,
>
> -- -- and is simply a pointer, but I'm not sure how this works
> exactly.
>
> -- -- If I have to, I can always separate d from the struct
> definition.
It should be a pointer; this is fine.
--
You received this message because you are subscribed to the Google Groups
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
Visit this group at https://groups.google.com/group/capnproto.
To view this discussion on the web visit
https://groups.google.com/d/msgid/capnproto/155924159391.16242.16546599770289011703%40localhost.localdomain.
