21:48 <carado> hi, is it possible to have a single object which is a sort of a generic collection, so that i could do `object.insert[String]("hello")`, `object.insert[U32](5)`, `object.contains[U32](4)`, and stuff like that ?

21:48 <carado> what I don’t want is to have to modify the code of its class each time I can a new type that it can contain values of

21:49 <SeanTAllen> not sure what you are asking

21:49 <SeanTAllen> are you saying you want it to be able to hold string and U32 at the same time?

21:49 <SeanTAllen> or that one instance holds Strings and another holds U32s?

21:56 <carado> the same instances, holds a set of String and a set of U32

21:56 <carado> and a set of Float if I suddenly want to add some Floats in the mix

22:01 <SeanTAllen> no

22:01 <SeanTAllen> you cant do that

22:01 <SeanTAllen> the only way you can do that is to make it an Any

22:01 <SeanTAllen> and then you would have to match on the Any to get it back to whatever type it might be

22:02 <SeanTAllen> and even that probably isnt what you want

22:03 <carado> it’s the closest i’ll be able to get, i think

22:03 <jemc> you can use a type union if you know ahead of time which types you're intending to mix

22:04 <jemc> it would be interesting to know more about your use case, because we might be able to suggest a more idiomatic approach

22:04 <jemc> (a type union would have many of the same issues as using `Any`)

22:05 <carado> well, what I really want to do is a generic message bus which I can hold as a single objects

22:06 <carado> it’ll have a set of hooks for various types of messages, receive messages, and route the messages appropriately.

22:07 <carado> and, I would like to be able to add a message type to my code without updating the message bus’s code

22:10 <jemc> well, if you want to use that kind of pattern, I'd suggest not having your "generic message" be a collection, but just a wrapper for a single object (with a type)

22:10 <jemc> for example you could create a class called `MyCoolMessage` that has the fields that you need for that type of message

22:12 <jemc> then, assuming you're using deeply immutable messages (`val`), you generic message wrapper could have a field of type `Any val`, which allows you to assign an instance of `MyCoolMessage val` to it

22:13 <jemc> in your receiving code, you'd do a `match` statement where one of the clauses matched for the type `MyCoolMessage val` and handled it with the proper application logic for that type of message

22:13 <jemc> it should all work just fine, but it still might not be most idiomatic for Pony

22:13 <jemc> (depending on what you're doing at a higher level)

22:13 <carado> so all hooks take as argument to apply() an Any and do match of a single type ?

22:14 <jemc> or maybe a match including a clause for any kind of message they care about handling

22:14 <jemc> which could be just one type in a simple case

22:15 <carado> at a higher level, I’m considering using pony for a video game, in which I’d like to make some things (window, network input, keyboard input) produce messages without having to worry about who receives them (and have multiple receivers)

22:17 <jemc> here's an idea for a different approach that may be a little more idiomatic, if it works for you

22:18 <jemc> in pony, a behaviour is already a handler for an event message in a mailbox, so it seems a little bit of an anti-pattern to recreate that pattern on top of it

22:20 <jemc> that is, if I create a behaviour `be foo(a: U32, b: String)`, it's effectively already a hook for handling events of `foo` with a message object that holds a `U32` and a `String`

22:21 <jemc> the trick in your case is getting the event publishers to talk to the event subscribers without your central routing bus needing to know about every possible behaviour you might want to implement in the future

22:22 <jemc> I think you can do this with a combination of interfaces and type parameters

22:23 <jemc> let's say your message bus is called `World`

22:24 <jemc> and let's say you want to have a message type for keyboard input called `handle_keystroke` that takes a `U64` for the `key_code`

22:25 <jemc> you could create an `interface KeyboardListener be handle_keystroke(U64: key_code)`

22:26 <jemc> then from your code that actually receives the incoming keyboard events, you access the world, then use that interface as a way of refining the subscribers that you care to talk to

22:26 <jemc> for example

22:27 <jemc> `world.access_each[KeyboardListener]({(listener: KeyboardListener) => listener.handle_keystroke(99) })`

22:29 <jemc> `access_each` would be a method that loops over every listener registered in the world, uses `match` to see if it is of type `KeyboardListener`, and if so, pass it to the given lambda function

22:30 <jemc> which could be a little inefficient in a very large world, but it's a decent start and there would be ways of improving performance from there

22:30 <jemc> the main point is that `KeyboardListener` is a type parameter, so the `access_each` method is generic and the `World` doesn't have to know anything about the interface you're asking for

22:31 <jemc> the idea is a bit of a variation on the "access pattern" I wrote up a while ago: https://github.com/ponylang/pony-patterns/blob/master/async/access.md

22:32 <jemc> the variation is that instead of an actor giving access to itself, it would be giving (external, tag) access to other actors based on their matching of the given type

22:32 <jemc> so I guess it's not really that similar :P

22:33 <jemc> if that sounds like something you'd want to try, but need help with figuring out the implementation, let me know

22:47 <carado> mmh

22:48 <carado> so `access_each` has to be called by every hook every time a message comes in just in case one of them catches it ?

22:49 <carado> i’m not really sure i get it, but i’ll read your link and see what i can figure out. anyway, thanks a lot !

23:45 <jemc> carado: `access_each` would be called by those *publishing* events

23:46 <jemc> the subscribers of events would simply receive a call to their `handle_keystroke` behaviour without having to do anything special to listen (other than registering with your `World`)