Generics vs. Classes?

[unlimitedscolobb]

Hi,

A general knowledge question: what would be the typical use cases of Racket generics vs. the typical use cases of Racket classes?

Am I correct in assuming that I can do everything with classes what I could do with generics, and that generics have made their way into the language before the classes?

-

Sergiu

P.S. I'm reading the section on classes in the updated Typed Racket reference, and I'm very happy to see this new functionality!  Very good job the Typed Racket Team!

[jackh...@gmail.com]

The typical use case for classes in Racket is writing GUIs, and that's mostly because the GUI framework is class based.

For most other use cases, generics are a better choice than classes. They're simpler and have a less intrusive effect on your API surface. If you don't need to support arbitrary user implementations, you can avoid generics and classes altogether and use structs whose fields contain functions.

[unlimitedscolobb]

Thank you for you answer!  I'll need to think more about it.  The idea of having structs whose fields contain functions has never occurred to me, but it may actually fit my relatively simple use case (and the planned migration to Typed Racket).

-

Sergiu

[Hendrik Boom]

On Sun, Nov 08, 2020 at 12:47:11PM -0800, unlimitedscolobb wrote:
> Thank you for you answer! I'll need to think more about it. The idea of
> having structs whose fields contain functions has never occurred to me, but
> it may actually fit my relatively simple use case (and the planned
> migration to Typed Racket).

Historical note:

I first encountered structures containing function in the source code for
OS/360 way back in the late 60's. In assembler.

-- hendrik

[Kieron Hardy]

> On Nov 8, 2020, at 2:58 PM, Hendrik Boom <hen...@topoi.pooq.com> wrote:
>
>> On Sun, Nov 08, 2020 at 12:47:11PM -0800, unlimitedscolobb wrote:

>> The idea of having structs whose fields contain functions has never occurred to me ...

>
> Historical note:
>
> I first encountered structures containing function in the source code for
> OS/360 way back in the late 60's. In assembler.
>
> -- hendrik
>

Structures with fields containing functions has never occurred to me before, either, at least not in those terms.

However isn’t that exactly one of the key design principles behind how device-drivers are implemented and installed into an OS? And also how classes and objects were initially added to C as some pretty hairy #define macros and function pointers?

This design pattern insight would have been beneficial to me sooner - doh!

— Kieron

[unlimitedscolobb]

On Monday, November 9, 2020 at 1:51:05 AM UTC+1 Kieron Hardy wrote:

> On Nov 8, 2020, at 2:58 PM, Hendrik Boom <hen...@topoi.pooq.com> wrote:
>
>> On Sun, Nov 08, 2020 at 12:47:11PM -0800, unlimitedscolobb wrote:
>> The idea of having structs whose fields contain functions has never occurred to me ...
>
> Historical note:
>
> I first encountered structures containing function in the source code for
> OS/360 way back in the late 60's. In assembler.
>

Structures with fields containing functions has never occurred to me before, either, at least not in those terms.

However isn’t that exactly one of the key design principles behind how device-drivers are implemented and installed into an OS? And also how classes and objects were initially added to C as some pretty hairy #define macros and function pointers?

This design pattern insight would have been beneficial to me sooner - doh!

 

I completely share your feelings Kieron.  In fact, I have already defined structures with functions in the fields multiple times and in many programming languages, but I have never thought how this pattern could be used to implement generic-like functionality :D

Thank you Hendrik for the historical note!

-

Sergiu

[jackh...@gmail.com]

I'm glad, I didn't expect my comment to be so helpful :)

For those curious, I have several examples of this pattern in Rebellion. The following constructs are all just structs of functions:

• Comparators
• Converters
• Equivalence relations
• Reducers
• Transducers