I also find this problem annoying and would be very interested in a linguistic solution (or alternatively a reason why I shouldn't be getting myself into this problem so often).
Recently I've been trying to work this by writing functions like this, which at least abstract out the boilerplate: > (define (make-foo-mixin foo-field-key) > (define-member-name the-foo foo-field-key) > (mixin () () > (inspect #f) > (super-new) > (inherit-field the-foo) > (public* > [my-method (λ () (send the-foo my-method))] > [another-method (λ (arg) (send the-foo another-method arg))] > ))) I would also note that essentially the same issue applies to programming with racket/generic. -Philip On Thu, Mar 30, 2017 at 8:10 AM, Erich Rast <er...@snafu.de> wrote: > 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. > -- 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.
