64 Replies
can i specify its a memebr is public or private or like rust i can do
pub(super) or pub(crate)no access modifiers, instead we use an underscore prefix to say something shouldn't be used in typical situations
The lsp also follows the convention and hides things like
var _data from the list of membersWe don't have them yet, but I know it was something that is hoped for in some form
i hope they never land
imo access modifiers are not worth it
Upsides and downsides. I've seen a lot of people get stuck on particular versions of libraries because they broke encapsulation, on the other hand I have also wanted to override the stupid decision of a library author.
No access modifiers means that people need to be very disciplined about how they break encapsulation if they do it, most people are not disciplined.
not to mention if you want to access private anyways, you always can with reflection
it just makes it more difficut, which could be an upside
I think that may be a good solution. Reflection provides the final "no I actually want to see this" hammer, but it's far enough away from normal code to be easy to review, and we can force error handling for reflection in case a field is missing.
But you have access modifiers for normal code.
I spent a good chunk of my prior job trying to counter low discipline, and in my current job maintain 50 years of poor discipline expressed through the medium of VAX assembly. At this point my trust in the average programmer (which includes myself) is almost non existent
The more ways I can child-lock a piece of code, the better
I feel like as long as the lib writer is using underscores properly on all the things that should be private if someone wants to play with fire and shoots themselves in the foot that’s on them.
Since you can break invariants and cause memory safety issues, I think it should be behind some kind of interface that is marked unsafe.
But we don't have a uniform way to indicate something as unsafe.
You make the function call named
unsafe_...That’s fair, maybe we should have a decorator that produces a compiler warning?
If you have to use it in a bunch of places that could get annoying, but a decorator with a well known name you can grep for would be fine.
If it's a constructor marked
@implicit, you won't be able to reliably find and check all usages. But perhaps this can only be described in coding guidelines.ex:
I feel like "Don't make an implicit constructor which can cause UB" should be in the coding guidelines.
This seems to be in the same category as not using
unsafe in Rust for anything truly unsafe. This can only be described in guidelines.Ideally, we should minimize implicit constructors, since they put extra pressure on the compiler.
Congrats @Owen Hilyard, you just advanced to level 27!
Yeah it’s nice for stuff like ‘Variant’ but generally not something people should be using very often
Whatever we land on though I’d rather not have to write ‘pub’ everywhere like you do in rust
Chris has said he likes the Python style where the entire language community has agreed on a style, but people are allowed to break them.
Maybe linters can help here
Yes, but python doesn't have ways to easily make your program segfault if you touch the wrong thing. Also, most "introduction to python" courses and blog posts don't cover that convention, meaning some people are unaware. I'm of the opinion knowing enough about the language to be able to use reflection means you know enough to make reasonable decisions about when to break encapsulation.
I agree on that front that most novice python programmers don't have a proper understanding of "private" and "public" interfaces so even if we don't explicitly forbid it, we need a mechanism for communicating "Hey you really shouldn't be touching this"
We can have the compiler enforce access modifiers and say "This member is private and inaccessible outside of the file/package/whatever the type is declared in".
We can also wait and see what C++ figures out.
Since they need to figure out how to handle public/private for reflection now.
Yes but as Kennit mentioned I'm not sure the team wishes to do that. If we do though, I don't know if this is a controversial take but I actually like the C++ style of declaring "blocks" of stuff with a particular access modifier
I think it will be more palatable once an escape hatch exists, meaning reflection.
Very much not a fan of the C++ style since they make parsing and code generation harder (especially code generation in the middle of a class block).
It's one of the many, many reasons why everyone uses clang to parse C++ instead of just building a parser optimized for what they need like other languages do.
ah fair enough, I'm not really knowledgeable about compiler woes but that makes sense
block vs per-member shouldn't be terribly different, you carry forward a tiny bit of state--you can actually stay context-free from a theory standpoint still (though with a doubling of your states along that run)
Access modifiers are on my list of things that python got right, along with block brackets and line delimiters
and integers
although the implementation of integers is a bit strange, but works for python
I guess I'm curious the arguments against providing a mechanism for locking away state behind a boundary. Even if the default is public, being able to seal away, say, munging the
capacity field on a List/Vec against external modification is necessary from an adversarial PoV, and can let library authors preempt a lot of bug reports by raising the bar for how much effort you need to put in to break thingswell to me it's one of those things that people complain about in theory, but in practice is not actually worth having
arbitrary precision ints ends up being a massive performance/optimization footgun unfortunately
yeah that ones a little different than the others, i've already talked about that enough
This might just be a result of different experiences, but access modifiers would have prevented some horrible abuses I've seen in codebases over my current and previous job
@Owen Hilyard I feel like you probably have seen similar in DTS?
most of the languages without access modifiers are interpreted
Yes, Cisco's traffic generator is stuck on a 6 year old version of a library because they broke encapsulation on it.
I speak of two ends of the spectrum:
Python (prior job, plus aforementioned DTS)
Hand written assembly (current job)
Although I guess that was 6 years old 2 years ago, so 8 years.
I've also seen some horrible sins committed in C along similar tracks
They are also now stuck on an EOL version of python as a result.
Proper encapsulation was a hard-fought win that came out of not being able to wrangle discipline out of people writing assembly, C, Fortran, etc
Scripting/interpreted languages were initially seen as "glue" code where your codebases wouldn't really get large enough for it to be necessary, but especially with Mojo I don't think we can assume codebases+deps will stay "tiny" any more than we could rightly assume that about Python
whats the reason they broke ecapsulation, was it no access midifiers or just bad design
the former can enable the latter, IME
The library was missing the ability to modify some fields of IPv6 headers. Instead of implementing that upstream they decided to break encapsulation because it was "easier".
Now that I think about we use a private header from Qt at work lol
And if Qt has normal stability policies they can decide to rewrite that in a security patch or a bugfix release.
It makes it much harder to upgrade if you do anything like that at all, and the senior engineers for the project need to document and be aware of where you do it so they can check if things break for new updates.
Fortunately it's just for
QZipReader which I have no idea why its not a public class and we have a test case that covers it, but due to Qt groups clear hatred of their customers thats the least of our worries when it comes time to upgrade
We did 5.15 -> 6.5 this year and yeesh
Took several of us a couple months to get everything stable againI can't say I disagree
I'd love to bench that against QATzip at some point, even the software fallback gets a lot of attention from Intel.
GitHub
GitHub - intel/QATzip: Compression Library accelerated by Intel® Qu...
Compression Library accelerated by Intel® QuickAssist Technology - intel/QATzip
Although I guess that probably doesn't take in a QFile and return a QString or a QVector, since Qt feels the need to rewrite the universe themselves.
Oh I imagine we have better options but then we're just introducing another dependency we won't keep up to date lmao
The main benefit is hardware acceleration on newer Xeons.
It will unzip ~50 GB per second of data per device, and there's one device per core cluster.
yeah thats a tad overkill it's just used to unzip a bundle of like 30 text files
Its better than having dead silicon on the CPU.
Eh, dev time isn't free, and often silicon (even unused) is "cheaper"
That's fair.
I'm a bit overused to throwing tons of data around.
I get bonked with "YAGNI" with frequency at work from having that impulse too
Yeah fortunately in user app land we get to play by a looser set of rules
But, we get the fun toys.
Yeah honestly I hate it here I've been trying to get out (kinda) for like a year
That's fair.
I think a lot of us are hoping that "Mojo stdlib contributor" becomes a good resume line.
or a job 👀
Also an option.
mood, on both