Mutual exclusivity of Defensible Classes/Class Fields, functional `import()`/Nested Imports about proposals HOT 6 CLOSED

I think this bug would be better for the class fields repository, but to briefly answer your question: private state is a necessary feature of any defensible classes proposal. Without the ability to keep some things strongly internal, how can you defend against anything?

I don't see the relation between the import proposals that you're raising (again, better to file this as a bug in one of the repositories). import() is used for dynamic cases, whereas other import statement forms are better for static cases. Neither is "better" than the other.

from proposals.

Thanks for getting back!

Yeah, perhaps better is not the right word, but here's the thing:

Currently, import statements are statically analyzed before the rest of the module (please correct me if I'm mistaken). With that being the case, does that extend to nested imports? If nested imports are also statically analyzed before the rest of the module is loaded, you have some actual runtime implications: loading modules you would not otherwise have due to a codepath not being executed. So, really, having nested import statements, it seems to me almost like they would have to be lazily evaluated. If they're lazily evaluated and don't block, I'm not sure I understand how the two proposals are entirely different.

I'm going to raise this as an issue on the nested import repo, as you mentioned I should do for Class Fields, I just wanted to clear the air of this being about the objectivity of certain proposals or a system based on preference as opposed to merit of the actual individual proposals.

As for Class Fields, I would raise an issue on the repository itself, but I have no qualms against the proposal except for perhaps a more definitive understanding of whether the "#" can be applied to methods belonging to class instances and how that grammar would apply to static methods (i.e.: Java's private static). I'm not even sure that's possible.

My concern is the value add of Defensible Classes or some explanation of how that is different than the proposal for Class Fields. What is or would be included in that proposal? This may bear no relevance to the Class Fields proposal itself. Are there meeting notes from which we can pull a better description for Defensible Classes?

from proposals.

Oh, cool, thanks for the link to the proposal, although it doesn't quite clear up all of the questions that have been called out in this issue, I'm glad it's well-defined somewhere.

from proposals.

Please see the follow-on private methods proposal for allowing # to be applied to methods. It's not included in the Stage 3 fields proposal; it's a separate Stage 2 proposal.

from proposals.

For more details on the status of defensible classes, I'd recommend getting in touch with @erights.

from proposals.

OK, let's keep talking on those specific repositories.

from proposals.