Kentaro Hara
2018-12-04 13:46:26 UTC
My key point is just that Blink should be aligned with Chromium's policy :)
Is there anyone who is familiar with Chromium's policy about sub namespaces?
Kentaro Hara, Tokyo, Japan
Is there anyone who is familiar with Chromium's policy about sub namespaces?
Is there any downside* of sub-namespaces except for more verbose code when
(non-Blink/WebKit) codebase for years, and both of them effectively use
namespaces. I'm accustomed to use of namespaces. I don't see any major
downside just because I'm accustomed to namespaces, I'm not saying there is
no downside. Personally the biggest pain point to me is that we need to
design or choose the policy of namespaces, not any technical issue.
My personal observation is that, if we'd like to follow the Chromium's
namespace style, "::blink::bindings::internal" would be the best name for
things that we'd like to hide. In case of Chromium, it's okay to access
blink::bindings::Foo from outside of blink::bindings, but it's forbidden by
policy to access blink::bindings::internal::Foo from outside of
blink::bindings. Each component may have its own "internal" namespace.
My key point here is "I want a (sub)namespace for bindings", and I don't
stick to a specific name. If people agree on "bindings_internal" or
whatever the name is, then I'm fine to follow the name.
Cheers,
Yuki Shiino
--mixing objects in different namespaces?
I have no idea. I've worked on Google-internal codebase and then Chromium(non-Blink/WebKit) codebase for years, and both of them effectively use
namespaces. I'm accustomed to use of namespaces. I don't see any major
downside just because I'm accustomed to namespaces, I'm not saying there is
no downside. Personally the biggest pain point to me is that we need to
design or choose the policy of namespaces, not any technical issue.
My personal observation is that, if we'd like to follow the Chromium's
namespace style, "::blink::bindings::internal" would be the best name for
things that we'd like to hide. In case of Chromium, it's okay to access
blink::bindings::Foo from outside of blink::bindings, but it's forbidden by
policy to access blink::bindings::internal::Foo from outside of
blink::bindings. Each component may have its own "internal" namespace.
My key point here is "I want a (sub)namespace for bindings", and I don't
stick to a specific name. If people agree on "bindings_internal" or
whatever the name is, then I'm fine to follow the name.
Cheers,
Yuki Shiino
Is there any downside* of sub-namespaces except for more verbose code
when mixing objects in different namespaces?
I've been over the Chromium code base a couple of times in the jumbo
project and regardless of what the guides say, there are "internal"
namespaces everywhere. I think it's mostly a convention to just have one
sub namespace and name it "internal" though.
I like the idea of ::blink::bindings_internal. Just ::blink::internal
seems strange since ::blink is already split into a public and an internal
part (both in ::blink) and most of the code is internal. This is supposed
to be even more specifically internal.
/Daniel
*) Not including the problems you get when you name your sub-namespace
the same as a top level namespace. Don't do that.
On Tue, 04 Dec 2018 10:59:51 +0100, Michael Lippautz <
I lack context of older proposals in the past but think this would be a
good idea as there's lots of things that are auto-generated or only for
internal use.
I have had similar feelings about heap/ where I'd rather hide internals
behind a (e.g. ::heap) namespace than have it exposed and be used by
accident (because the types autocomplete and/or it looks like a good idea
to bypass layers).
-Michael
You received this message because you are subscribed to the Google Groups
"platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
To post to this group, send email to
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAH%2BmL5AdExBkgpu2hwdS%3DaCgBHu5wwL3375qTgYzLsTkXkK5UQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAH%2BmL5AdExBkgpu2hwdS%3DaCgBHu5wwL3375qTgYzLsTkXkK5UQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
/* Opera Software, Linköping, Sweden: CET (UTC+1) */
when mixing objects in different namespaces?
I've been over the Chromium code base a couple of times in the jumbo
project and regardless of what the guides say, there are "internal"
namespaces everywhere. I think it's mostly a convention to just have one
sub namespace and name it "internal" though.
I like the idea of ::blink::bindings_internal. Just ::blink::internal
seems strange since ::blink is already split into a public and an internal
part (both in ::blink) and most of the code is internal. This is supposed
to be even more specifically internal.
/Daniel
*) Not including the problems you get when you name your sub-namespace
the same as a top level namespace. Don't do that.
On Tue, 04 Dec 2018 10:59:51 +0100, Michael Lippautz <
I lack context of older proposals in the past but think this would be a
good idea as there's lots of things that are auto-generated or only for
internal use.
I have had similar feelings about heap/ where I'd rather hide internals
behind a (e.g. ::heap) namespace than have it exposed and be used by
accident (because the types autocomplete and/or it looks like a good idea
to bypass layers).
-Michael
Ah, I was thinking about creating something like
blink::bindings_internal. I'm not sure the number of interfaces you want to
expose to blink:: vs. the number of interfaces you don't want to expose. If
the latter is small it may make sense to have an internal namespace rather
than having a ton of expose statements.
Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
To post to this group, send email to
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABihn6FvxiNoBTQt3tR4H0j-ZTa0inf-ThS%2B5942v4V_487UUQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABihn6FvxiNoBTQt3tR4H0j-ZTa0inf-ThS%2B5942v4V_487UUQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--blink::bindings_internal. I'm not sure the number of interfaces you want to
expose to blink:: vs. the number of interfaces you don't want to expose. If
the latter is small it may make sense to have an internal namespace rather
than having a ton of expose statements.
What's a guideline for adding namespaces in Chromium?
I didn't find a topic about namespace in Chromium C++ style guide
<https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md>
(except for unnamed namespaces). It looks to me that Chromium has
namespace per component when the component is considered having reasonable
size.
Is it an option to have an "internal" namespace for classes/functions
"blink::", however, it doesn't look great to me.
Just for a reference, Google C++ style guide
<https://google.github.io/styleguide/cppguide.html> (that Chromium C++
global namespace. If everything (or many things) is going to be placed in
"blink::internal::", then "blink::internal::" would be like another global
namespace, I'm afraid.
Cheers,
Yuki Shiino
You received this message because you are subscribed to the GoogleI didn't find a topic about namespace in Chromium C++ style guide
<https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md>
(except for unnamed namespaces). It looks to me that Chromium has
namespace per component when the component is considered having reasonable
size.
Is it an option to have an "internal" namespace for classes/functions
you want to hide?
Everything in "blink::internal::" looks better to me than everything in"blink::", however, it doesn't look great to me.
Just for a reference, Google C++ style guide
<https://google.github.io/styleguide/cppguide.html> (that Chromium C++
Be mindful of our scaleWith a codebase of 100+ million lines and
thousands of engineers, some mistakes and simplifications for one engineer
can become costly for many. For instance it's particularly important to
avoid polluting the global namespace: name collisions across a codebase of
hundreds of millions of lines are difficult to work with and hard to avoid
if everyone puts things into the global namespace.
When I'm working on Blink codebase, I think "blink::" is a (sort of)thousands of engineers, some mistakes and simplifications for one engineer
can become costly for many. For instance it's particularly important to
avoid polluting the global namespace: name collisions across a codebase of
hundreds of millions of lines are difficult to work with and hard to avoid
if everyone puts things into the global namespace.
global namespace. If everything (or many things) is going to be placed in
"blink::internal::", then "blink::internal::" would be like another global
namespace, I'm afraid.
Cheers,
Yuki Shiino
Is it an option to have an "internal" namespace for classes/functions
you want to hide?
you want to hide?
What's a guideline for adding namespaces in Chromium?
I support adding sub namespaces to bindings/ but want to do that in a
way that aligns with what Chromium is doing.
Kentaro Hara, Tokyo, Japan
--
You received this message because you are subscribed to the Google
Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it,
To post to this group, send email to
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jwepO%3DYH88Dz_oeA3r%3DTUax2nj53A10BTeYb46aeAeT0A%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jwepO%3DYH88Dz_oeA3r%3DTUax2nj53A10BTeYb46aeAeT0A%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--I support adding sub namespaces to bindings/ but want to do that in a
way that aligns with what Chromium is doing.
Hi team,
I wish that bindings could have its own namespace for Blink-V8
bindings code, like blink::binding:: or blink::bindings:: or
blink::v8bind:: or whatever the name is.
I know that there were discussions about introducing sub namespaces
in blink:: namespace. Some people supported some sub namespaces and some
other people didn't. I'm not pretty sure what the conclusion was, and I'd
vaguely remember that there was no good consensus at that time?
Now I'd like to ask you folks whether it's okay to introduce a new
namespace for bindings. What do you folks think?
Background: Blink-V8 bindings is not so small component, and not all
the classes and functions are meant to be public. Some classes and
functions are only meant for auto-generated bindings code and no other
Blink code is expected to use such classes and functions. I don't want to
pollute the global namespace with such a class. I think that it's okay to
put common bindings APIs in blink:: namespace so that we don't need to
write bindings::ScriptState for example every time.
Cheers,
Yuki Shiino
--I wish that bindings could have its own namespace for Blink-V8
bindings code, like blink::binding:: or blink::bindings:: or
blink::v8bind:: or whatever the name is.
I know that there were discussions about introducing sub namespaces
in blink:: namespace. Some people supported some sub namespaces and some
other people didn't. I'm not pretty sure what the conclusion was, and I'd
vaguely remember that there was no good consensus at that time?
Now I'd like to ask you folks whether it's okay to introduce a new
namespace for bindings. What do you folks think?
Background: Blink-V8 bindings is not so small component, and not all
the classes and functions are meant to be public. Some classes and
functions are only meant for auto-generated bindings code and no other
Blink code is expected to use such classes and functions. I don't want to
pollute the global namespace with such a class. I think that it's okay to
put common bindings APIs in blink:: namespace so that we don't need to
write bindings::ScriptState for example every time.
Cheers,
Yuki Shiino
Kentaro Hara, Tokyo, Japan
--
You received this message because you are subscribed to the Google
Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it,
To post to this group, send email to
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jwepO%3DYH88Dz_oeA3r%3DTUax2nj53A10BTeYb46aeAeT0A%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jwepO%3DYH88Dz_oeA3r%3DTUax2nj53A10BTeYb46aeAeT0A%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
To post to this group, send email to
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABihn6FvxiNoBTQt3tR4H0j-ZTa0inf-ThS%2B5942v4V_487UUQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABihn6FvxiNoBTQt3tR4H0j-ZTa0inf-ThS%2B5942v4V_487UUQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
You received this message because you are subscribed to the Google Groups
"platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
To post to this group, send email to
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAH%2BmL5AdExBkgpu2hwdS%3DaCgBHu5wwL3375qTgYzLsTkXkK5UQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAH%2BmL5AdExBkgpu2hwdS%3DaCgBHu5wwL3375qTgYzLsTkXkK5UQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
/* Opera Software, Linköping, Sweden: CET (UTC+1) */
Kentaro Hara, Tokyo, Japan
--
--
Chromium Developers mailing list: chromium-***@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CABg10jz9jByzA1OdSxS1jG1L0qS4E6OawZskhBdCGFvye2Ve2w%40mail.gmail.com.
--
Chromium Developers mailing list: chromium-***@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CABg10jz9jByzA1OdSxS1jG1L0qS4E6OawZskhBdCGFvye2Ve2w%40mail.gmail.com.