New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Class definition syntax restrictions #7529
Comments
Comment author: @dra27 I think it is fair to say that no decision in the language was taken with a view to making any part of the language less usable. In the first instance, there are already two ways of writing what you want: class c = let r = ref [] in let () = r := [1] in object end and (admittedly only for your specific example): class c = let r = {contents = [1]} in object end There are also initializer, though the semantics are of course different (evaluate at object creation rather than class definition): class c = let r = ref [] in object initializer r := [1] end Does generalising class definition to be a sequence ending in a object really add much-needed expressive power? |
Comment author: @dra27 For the second case, I expect the class sub-language was simply not considered when let open was added to the language - perhaps Alain has thoughts on this? It seems like a reasonable thing to add to me. |
Comment author: mookid I am aware of this workaround. My point is that in most cases (recursive definition aside), changing an object definition to a class definition should be a matter of changing one "let" to "class". I consider any additional required change as a failure. And contrary to some other dubious syntactic characteristics (in particular,"f -1" not being "f (-1)", for instance), fixing it would probably not break existing code. |
Comment author: @alainfrisch |
Comment author: @alainfrisch "let open" as been added. For sequencing, there exists a trivial and local syntactic rewriting ("e; ce" => "let () = e in ce"). I don't think this deserves any particular treatment at the language level. A local module binding (and module patterns) would seem be more useful, but Jacques mentions in #6271 that this would be quite difficult (presumably to ensure that types from the module don't escape). |
Original bug ID: 7529
Reporter: mookid
Assigned to: @alainfrisch
Status: resolved (set by @alainfrisch on 2017-07-20T07:25:44Z)
Resolution: fixed
Priority: normal
Severity: feature
Category: language features
Duplicate of: #6271
Bug description
Compared to value definitions, class definitions have several restrictions. They have to be in the form
In particular, the following two are not valid syntactic expressions:
Is there any rationale behind these two restrictions, besides making the class sub-language less usable?
The text was updated successfully, but these errors were encountered: