On Sunday, 24 August 2014 at 14:15:25 UTC, Kagamin wrote:
On Sunday, 24 August 2014 at 02:22:41 UTC, Dicebot wrote:
Well difference is that "internal" substring in the fully
qualified name that is much more likely to tell user he is
better to not touch it. However, original Kagamin proposal of
embedding it into module names themselves does address that if
you are ok with resulting uglyness.
Both ways it's a convention, and I don't see, why such
convention should exist in the first place, member protection
has nothing to do with module name, which reflects module's
Because we have no other means of enforcing this protection -
this is why my PR event exists.
On Sunday, 24 August 2014 at 02:34:01 UTC, Dicebot wrote:
It can be a philosophical matter, but in my experience
grouping by functionality is genuine, and access is an
afterthought, so grouping by access doesn't work in the long
term, as code naturally (spontaneously) groups by
That does contradict your statement that any stuff used in
parent packages must go to up the hierarchy which is exactly
grouping by access :)
Access there means protection, usage reflects functionality.
And how that makes your statement less contradictive?
I can probably give a more practical example <...>
1. Making wrapper protected will preclude writing new
2. Using wrapper methods can be meaningless without serializer.
3. Serializer may just not expose wrapper, then user will have
no way to access it.
4. .net has quite a lot of things like
and nothing explodes even though .net programmers are believed
to be really stupid and evil. It's a virtue of Stackoverflow
I am afraid I don't really understand what your point here is -
that my design is wrong and must be banned or that package
concept is flawed and must be reworked? Neither is really an
There is a simple and strict requirement - no one must be able to
extend serializers but few developers that routinely maintain
that package (and all sub-packages). Never in user code. This
idea is not a subject to reconsideration - if language says such
design is illegal I am going to call that language bullshit.
I'm afraid, hierarchies make things harder to find. If you
don't know what is where, flat organization will present you
with everything readily available right before your eyes. With
deep hierarchy you're left with abstract or poorly chosen
categories at every hierarchy level, so effectively you have to
walk the entire hierarchy, which is much more tedious than
scroll a flat list of modules viewing ten modules per scroll.
Badly named list of modules (like what we have now in phobos)
scales well up to 100, well-named list is much more manageable:
if you need xml, you already know it's near the end of the list
- it's easy to find even among 1000 files - you don't ever need
to scroll entire list. If it's not there, where do you go?
There's no obvious answer. So even shallow hierarchy is more
troublesome than a flat list of 1000 modules. I don't believe
hierarchy will magically solve navigation problems just because
it has folders.
You are speaking about _finding_ things. I am speaking about
_discovering_ things. See the difference? There is no way you can
quickly tell "aha, so this data formats are supported out of the
box" when looking at plain flat list of 1000 files. With solid
hierarchy it becomes trivial.
And System.Xml is not System.Text.Xml, System.Net is not
System.IO.Net - where is deep hierarchy? If you want
System.Xml, you type `s.x` and it doesn't matter, how many
namespaces are there, you're presented with System.Xml. If it's
not there, where to find it, in System.Text, System.Formats,
System.Parsers, System.Lang, System.Markup, System.Sgml?
You pick few that make most sense to you and ignore the rest. If
routinely needed module is not exposed via obvious path it is an
issue worth filing in the bug tracker. More rarely used / obscure
modules can have more surprising paths. I don't see a problem
here. Again, searching for a known package is never a problem
both ways - you can just, well, run the search query.
Discoverability of uknowns is the key.