This seems like a trivial point because the class system doesn't have to track these things and they are in fact part of the closures of the methods, so I don't see in what sense they are "fields". Perhaps I am blinded by my reading of the implementation. I certainly agree they are essentially fields, but I can't but think of them as closed-over variables.<div> </div><div>Jay <div class="gmail_quote">On Thu, Dec 16, 2010 at 7:00 AM, Carl Eastlund <<a href="mailto:cce@ccs.neu.edu">cce@ccs.neu.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> To quote the class* documentation: (<a href="http://docs.racket-lang.org/reference/createclass.html#%28part._clfields%29" target="_blank">http://docs.racket-lang.org/reference/createclass.html#%28part._clfields%29</a>) "Each field, init-field, and non-method define-values clause in a class declares one or more new fields for the class. Fields declared with field or init-field are public." So only the public ones are accessible via get-field. Carl Eastlund <div><div></div><div class="h5"> On Thu, Dec 16, 2010 at 8:56 AM, Jay McCarthy <<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>> wrote: > Does 'define' really mean 'make a field'? I thought fields had to be > specially designated so that get-field would know about them... > Yes, this program errors: > #lang racket > (define c% > (class* object% () > (field [x 1]) > (define y 2) > (super-new))) > (define o (new c%)) > (field-names o) > (get-field x o) > (get-field y o) > -- > I agree that 'define' is like making a field, but fields are something > special too. > Jay > On Thu, Dec 16, 2010 at 6:51 AM, Robby Findler <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> > wrote: >> >> On Thu, Dec 16, 2010 at 12:22 AM, Mark Engelberg >> <<a href="mailto:mark.engelberg@gmail.com">mark.engelberg@gmail.com</a>> wrote: >> > OK, it works when the set! occurs after the super-new. I didn't think >> > set! >> > would work at all in a class definition (as opposed to within a method); >> > I >> > was thinking of the whole system of defining classes as more of a >> > declarative DSL that only allowed certain constructs. >> >> You've probably already figured this out, but the body of a class is a >> series of definitions and expressions like at the top-level but >> 'define' taking on the meaning of 'make a field', and a bunch of new >> definitions appearing. The new stuff says what the methods are, but >> everything else is just executed in sequence as if it were in the body >> of the initializer (if this were in Java, say). >> >> hth, >> Robby </div></div></blockquote></div> -- Jay McCarthy <<a href="mailto:jay@cs.byu.edu" target="_blank">jay@cs.byu.edu</a>> Assistant Professor / Brigham Young University <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a> "The glory of God is Intelligence" - D&C 93 </div>