Fix #2529: explicit protection package #3651

Kagamin via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Sun Aug 24 07:15:24 PDT 2014


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.

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.

> I can probably give a more practical example I have just 
> recently encountered when re-designing one of our internal 
> library packages. It was a "serialization" package and 
> sub-packages defined different (de)serialization models, some 
> of those defining special wrapper types for resulting data that 
> enforce certain semantics specific to that serialization model 
> via the type system. It is not surprising that most internal 
> details of such wrappers were kept package protected as 
> exposing those to user could have easily violated all 
> assumptions (but was needed to implement (de)serialization 
> efficiently).
>
> It has become more complicated when "meta-serializers" have 
> been added to parent package - templated stuff that took any of 
> sub-package implementations and added some functionality (like 
> versioning support) on top. Being generic thing it reside in 
> higher level "serialization" package but to be implemented 
> efficiently it needs access to those internal wrapper fields. 
> Moving wrapper modules to parent package is not an option here 
> because those are closely related to specific serialization 
> model. Exposing stuff as public is not an option because anyone 
> not deeply familiar with package implementation can easily 
> break all type system guarantees that way. Moving 
> "meta-serializers" to sub-packages is quite a code duplication.
>
> Right now I keep that stuff public and say in docs "please 
> don't use this" which is hardly a good solution.

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.

On Sunday, 24 August 2014 at 02:39:40 UTC, Dicebot wrote:
> On Saturday, 23 August 2014 at 09:00:30 UTC, Kagamin wrote:
>> What is difficult to find? With flat structure you have all 
>> files right before your eyes. If you need std.datetime.systime 
>> module, you open std/datetime/systime.d file - that's the 
>> reason of needlessly restricting code structure with modules 
>> as if one size fits all.
>
> It is the same reasoning as with deep filesystem hierarchies 
> and, well, any data hierarchies - once the element (module / 
> file) count becomes bigger than ~dozen you only really notice 
> things you know to look for. Contrary to that deeply nested 
> categorized hierarchies are easy to casually to search through 
> if you don't know exact module name - just iteratively pick 
> whatever package fits the theme until you find what you want.

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.

> I remember coding a bit in C#/.NET platform ages ago - it was 
> totally possible to find relevant modules without even looking 
> in docs, just using auto-complete through suggested package 
> names for import. It was really positive experience for a 
> newbie I was. At the same time a lot of people have no idea how 
> many cool things Phobos actually has.

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?


More information about the Digitalmars-d-announce mailing list