On Fri, Dec 26, 2014 at 2:40 PM, Jonathan S. Shapiro < [email protected]> wrote:
> While I have mixed feelings about the IDisposable pattern, it does seem to > me that it's a pattern that has served well in enough contexts to think > about carefully, and I think that the language support provided by the > "use" form is a reasonable thing to do. IDisposable kind of dodges the > bullet about closure capture because the captured reference refers to an > IDisposable that will have been disposed. > Speaking more from a C#/CLR perspective... Manual "disposing" is a reality, whether you give it a standardized construct or not. IMO, it's convenient to have the construct semi-standardized, instead of everyone inventing their own name for disposing. Though the actual details of Dispose are still often thorny (particularly WRT threading and non-managed handles). I find "use" is of much more limited utility, particularly because of the way the pattern is easily broken async, threaded-work-queues, and the like. Personally, I'd just assume not bother with "semi-working-scoped-destruction", and either go for "fully working" or let the programmer just call .Dispose(). If you are going to admit pattern matching (which we took out of BitC), > guarded patterns are the right thing. I have no foundational objection to > patterns. We took them out because pattern compilation was too damned > complicated and their use in combination with by-ref and mutable seemed to > offer lots of opportunities to make mistakes. I think we now know how to > avoid the mistakes, but I still feel ignorant about the compilation > complexity. > Personally, the pattern-like behavior I miss the most in modular-compilation-land is the ability for the compiler to statically validated that matching covers all cases. However, with modular compilation this requires all types used in the matching to be defined in the module the match exists in (so they can't later change after a dependent module update). I suspect this is one of the reasons most languages with solid matching are whole-program-compilers. For example, IMO modular-compilation-languages would be improved if they included some kind of module-private (or even class private) enum/switch, with no default case allowed, and the compiler complaining if any cases were missed. I know I would make liberal use of such a feature and my code would improve as s result. > Qualifier: my original dislike for record field names had to do with name > space pollution. But if they are only valid inside record constructors that > would mitigate a lot of my dislike for them. There's still an issue in my > mind about Records vs. Maps, which I'll come to in a separate email. > > I'm confused by this. If field-names are only admitted inside record constructors, how does one refer to fields outside of the record constructor?
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
