Dear all, This is something I've been wondering for a long time and at the same time it's a suggestion for implementation, since I'm not familiar enough with higher Racket macrology.
Often when I define a class it contains instances of other classes. To access them as a user of an instance of the embedding class, you usually either (i) have to write an access wrapper method in the embedding class, or (ii) have to provide a getter method that returns the instance, so the 'client code' can access it directly. I believe (ii) is the general guideline used in the Racket source. Both result in a lot of boilerplate, (i) in the class definition and (ii) in the 'client code', especially if you have to additionally check that the object is initialized. My idea to reduce the boilerplate is to introduce a 'using' clause - or maybe there is a better term - that allows you to specify a class and some clauses similar to module exports. For example (maybe not the best syntax): (define foo% (class object% (using bar bar% (prefix-out bar: method1 method2)) ... (super-new))) This would define an instance bar of bar% in a field and methods bar:method1 and bar:method2 within foo% that automatically are handed down to bar, i.e., they should be equivalent to: (define/public (bar:method1 ...) (send bar method1 ...)) Of course, the normal case would be to use the embedded object without any renaming, if there are no name conflicts, and it should allow for arbitrary renaming and generally the same amount of control as module declarations. I assume that some fine control over initialization methods of classes that are embedded that way is also needed, e.g. a way is needed to use bar%'s initialization arguments as initialization arguments of foo% with optional renaming, and a way similar to super-new to provide bar's initialization arguments explicitly during initialization of foo%. I don't know of any OOP language that explicitly contains this kind of programming construct (maybe Java or Smalltalk?). Instead, I've seen a lot of boilerplate code in various languages to access embedded objects, and I have to admit that I write a lot of such code in Racket. Traits and Mixins get you closer to a solution, but do not seem to exemplify the same use pattern in general. Maybe this is not done because it violates some OOP principles or leads to an antipattern? If so, I'd be interested in hearing about it. If not, maybe some graduate student could implement it and write a paper about it? ;-) Anyway, I'd be interested in comments and in any case would love to have this an option in Racket's class system unless someone has a good argument against it. Best, Erich -- Dr. Erich H. Rast, Research Fellow IFILNOVA Institute of Philosophy Av. de Berna, 26 - 4ยบ Piso 1069-061 Lisbon, PORTUGAL http://home.snafu.de/erich/ https://fcsh-unl.academia.edu/ErichRast -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
