Fix #2529: explicit protection package #3651

Dicebot via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Mon Aug 25 13:35:15 PDT 2014


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.


More information about the Digitalmars-d-announce mailing list