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 functionality.

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 functionality.

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 <...>
code duplication.

1. Making wrapper protected will preclude writing new serializer.
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 http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.configuredtaskawaitable%28v=vs.110%29.aspx and nothing explodes even though .net programmers are believed to be really stupid and evil. It's a virtue of Stackoverflow Driven Development.

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 acceptable argument.

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.
              • R... Jacob Carlborg via Digitalmars-d-announce
              • R... Kagamin via Digitalmars-d-announce
              • R... Dicebot via Digitalmars-d-announce
            • Re: F... Kagamin via Digitalmars-d-announce
              • R... Kagamin via Digitalmars-d-announce
              • R... Dicebot via Digitalmars-d-announce
              • R... Kagamin via Digitalmars-d-announce
              • R... Dicebot via Digitalmars-d-announce
              • R... ketmar via Digitalmars-d-announce
              • R... Kagamin via Digitalmars-d-announce
              • R... Dicebot via Digitalmars-d-announce
              • R... Kagamin via Digitalmars-d-announce
              • R... Rory McGuire via Digitalmars-d-announce
              • R... ketmar via Digitalmars-d-announce
              • R... Andrei Alexandrescu via Digitalmars-d-announce
              • R... Dicebot via Digitalmars-d-announce
              • R... ketmar via Digitalmars-d-announce
              • R... Kagamin via Digitalmars-d-announce
  • Re: Fix #2529: explicit pro... Dmitry Olshansky via Digitalmars-d-announce

Reply via email to