-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
It would be nice to have initargs
defined for protobuf classes
#16
Comments
No good reason I think. There might be some trickiness with tracking which fields of the protobuf have been set. |
This uses (defmethod initialize-instance :after) methods to ensure that fields populated with :initargs are recorded into %has-bits%. Closes issue brown#16.
I had some time this weekend to experiment with your initarg patch. Thanks very much for sending it. Figuring out what initarg handling should look like is important. A proto3 implementation should have initargs support, for instance, and it would be excellent for the initarg APIs for proto2 and proto3 to be compatible. I found initargs to be hard to use in the presence of repeated fields. For instance, here's the existing code in the address book example to add a PERSON:
Here's the same function but using initargs:
The need to initialize a repeated field with an adjustable array makes the code much longer. Perhaps lists should be allowed as initarg arguments for repeated fields. I have to think more about how the design affects how proto3 support is implemented. |
I see your point, although I think there are other options for the above function in which initargs seems more readable (subjectively to my eye). E.g., (defun add-person (&key id name email-address phone-numbers
&aux (address-book (read-address-book)))
(vector-push-extend
(apply #'make-instance 'person
:id id
:name (pb:string-field name)
:phone (map 'vector (lambda (pair)
(destructuring-bind (type . number)
(make-instance 'person-phone-number
:number (pb:string-field number)
:type (ecase type
(mobile +person-phone-type-mobile+)
(home +person-phone-type-home+)
(work +person-phone-type-work+)))))
phone-numbers)
(when email-address (list :email (pb:string-field email-address))))
(person address-book))
(write-address-book address-book)
(values)) Although the above gives a vector, it is not extendable and might not satisfy the type checks on the (defmethod make-instance
((class (eql 'example)) &rest options &key &allow-other-keys)
(apply #'call-next-method class
(mapcar (lambda (opt)
(typecase opt
(list (make-array (length opt)
:initial-contents opt
:adjustable t
:fill-pointer t))
(t opt)))
options))) If this seems reasonable (I can see an argument that it is too fancy/unexpected) I could put together a patch to this effect. |
Ping. Any thoughts on this? |
Yes, sorry for not responding. I'll send a more substantive note in a bit.
…On Thu, Mar 19, 2020 at 3:42 PM Eric Schulte ***@***.***> wrote:
Ping. Any thoughts on this?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#16 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAGVMJ45CCW5BIZJ6ZHR6DRIJYR7ANCNFSM4KCSLLBQ>
.
|
This uses (defmethod initialize-instance :after) methods to ensure that fields populated with :initargs are recorded into %has-bits%. Closes issue brown#16.
This uses (defmethod initialize-instance :after) methods to ensure that fields populated with :initargs are recorded into %has-bits%. Closes issue brown#16.
Is there a reason this isn't done currently? Thanks
The text was updated successfully, but these errors were encountered: