Given that it's easy enough to create a /new/ class on Wednesday that has 3 arguments instead of 2, doesn't it make sense to constrain a given existing class to have a fixed structure? (just asking) Maybe it could also allow for some optimizations.
I wonder if such a additional constraint would break anything in the existing code. Laurent On Mon, Jun 9, 2014 at 8:33 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > At Fri, 6 Jun 2014 13:23:15 -0400, Asumu Takikawa wrote: > > On 2014-06-06 06:31:27 +0100, Matthew Flatt wrote: > > > Sorry for being so late to the discussion, but I agree that something > > > like `class-constructor-arity` and `class-constructor-arity-includes?` > > > should be added to `racket/class`. > > > > Are those even possible to implement? > > > > After all, I can construct a class that has 2 init arguments on > > Wednesday and has 3 on Friday (by checking the date and then using > > different `super-new` calls in the branches). > > Good point! The `make-object` function doesn't check arities or > argument names in advance; it has to wait to see what a initialization > expressions do. > > I think we could add a function that reports argument information for > simple classes, where "simple" is based on the relevant class > expressions conforming to syntactic constraints. The constraints would > be a simplified (and documented) variant of the constraints that are > currently used to determine whether use-before-definition checks are > needed for accesses of a field's classes. > > Is argument information useful enough to do that? > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users >
____________________ Racket Users list: http://lists.racket-lang.org/users