yes, and so did Oberon and then Go

the fact that all the popular languages other than Go don't use it is pretty messed up

it makes it a lot easier to create good names for things

i mean, how does C even make namespaces at all?

why are we still suffering from OOP nonsense when you can make filesystems and namespaces that are one and the same?

personally, i always call my directories the same name as the package i put inside them, and this is a common practise with #golang it's even a setting in intellij for Go, to automatically rename packages if you rename folders, and vice versa

may i suggest that you adopt the idea of just making the directories the names for referencing them? actually, there is no reason to repeat this!

Reply to this note

Please Login to reply.

Discussion

btw, there is one good reason to not make folders 1:1 with package names, that is the fact that filesystems don't respect the semantics of things like - and + and other operators, this is a waste of processing time to have to distinguish them

this is the best reason to have module name headers... i just hadn't thought about it that deeply, but the guys who designed Go have been drowning in computer programming for 40 years

The Go designers, the original ones are indeed balls deep in that 40 year + language design experience indeed.

yeah, the longer i use #golang the more i get it too...

the only thing i warn people about go is that maps and slices are funny with concurrency and be really careful about where you put channel operations and goroutines

there can be a tendency to go nuts on those two things, i think every go programmer goes through a phase of it

oh yeah, sometimes some people go nuts with interfaces - don't make them unless you already have a concrete type, or a plan to make multiple types, more often you don't need them and they create an unhelpful layer of indirection

the usual trigger for making interfaces fro me these days is noticing that i just made three sets of methods for types that were the same, then i am facepalm

Yep! Same

Slices have to be handled carefully in D to, or well by carefully I mean one must think when using them.

yeah, i remember when i first used a language with dynamic arrays

i kinda prefer static arrays to be honest, i always look at the code and think to myself "is this probably going to need a reallocation?" and try to avoid that

Defs agree!

The only times I have interfaces is when I know there are a few classes with behavior I need via an interface.

Well, other way round. Describe a behavior and implement it in many place.

yeah, there is definitely use for it... i just implemented a binary codec recently for database index keys, it is way cleaner than the previous offset laden code full of wordy and error prone constants (literals even) read and write are two examples that often come up... interface methods also tend to come in pairs, in general, not always... and yes, interfaces need to be small... there is an interface in my current project that i think could do without one idiotic method that doesn't do anything actually - an init function... another principle of #golang is to design structs so the zeros are reasonable defaults if they aren't, you can also handle that as a function called from methods that need a value other than zero to set the value to a reasonable default, then the interface is cleaner and the programmer can just throw these things in

The name resolution is tied to the module names. The strict headed option is only optional now because some unittests don't yet conform.

I will be defaulting it to true soon, once done with those tests.

Then yes, it enforces the matching of names to FS