-
Notifications
You must be signed in to change notification settings - Fork 26
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
Fix access specifiers in gadget
inheritance tree
#395
Conversation
234d6ae
to
aba0185
Compare
Also, most gadgets in |
Regarding consistency and explicitly specifying inheritence type, this makes sense to me (although it is a shame that this cannot be checked autmatically AFAIK). Regarding the type of inheritance, on reflection I'm a bit uneasy about changing it. Partly because a) b) Using So I wonder if we should just sort out the consistency and explicit visibility part in this PR, keep |
aba0185
to
b3a7294
Compare
Good point.
Yes, I did this (see last commit). Happy to keep it public for now. Note, as flagged in my previous messages, that nothing really changes much if we switch to another type of inheritance (if we use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@AntoineRondelet as discusses, I checked some of the classes in hash_stream.hpp. AFAICT, |
Thanks for having a look at these @dtebbs, no problem, don't have any pending changes here, so happy to merge. |
See: #394
As mentioned in the ticket linked above, the gadgets inheritances were inconsistent. Some gadgets like
joinsplit
orCOMM_gadget
had a private inheritance fromlibsnark::gadget
and all others inherited publicly. So far thelibsnark::gadget
class is very small. Only one constructor (public) and 2protected
attributes. As such, public inheritance is not an issue. I think that this "public scopes by default" behavior is not desired. Instead, we should be strict with scopes and group attributes/methods by access specifier to control the interface of the classes in order to expose the strict necessary in the public interface of each class, and we should useprivate
(orprotected
if needed) scopes by default and should modify this default behavior when usingpublic
scopes is justified. Likewise, we should specify scopes and access specifiers explicitly to crystalize the implementer's intention, instead of relying on default behavior. This allows to keep a good control over the children classes interfaces and forces to think about interfaces/API.[EDIT:] Edited message further to discussions below.