Hi, On Sun, Mar 1, 2026 at 9:05 PM Tim Düsterhus <[email protected]> wrote:
> Hi > > On 3/1/26 20:48, Jakub Zelenka wrote: > > The policy recommends consistency with existing symbols and there are > > already OpenSSLCertificate, OpenSSLCertificateSigningRequest and > > OpenSSLAsymmetricKey. So I think we should stick with no namespace here > and > > calls it OpenSSLSession and OpenSSLException. I will introduce that > > exception as I agree it makes more sense. > > The policy also states: > > > This is a somewhat loose guideline, and applies more strongly to > functions than classes. > > I don't feel strongly about the OpenSSLSession class, but I feel > strongly about the exception hierarchy: > > It should immediately be introduced into the namespace, because the > exception hierarchy is relevant to the entire extension (e.g. also to > newly namespaced bits) and namespacing it later will become messy. > > > existing extensions SHOULD follow the rules for newly introduced exceptions, but MAY diverge for consistency with existing symbols. The consistency is the key here. I really don't like introducing a namespace and have some classes in it and some not - that's really not a consistency then IMO. Kind regards, Jakub
