<svdvonde>
I understand that the TCPConnection actor synchronously invokes callbacks on the server (defined in the TCPConnectionNotify interface), but I was wondering if there is a particular reason as to why the Server is implemented as a class and not an actor (which would make more sense to me conceptually)
<Candle>
svdvonde: The TCPListener and the TCPConnection are both actors; the TCPListenNotify and the TCPConnectionNotify are the handlers; they are describing what to do on various events; and are called synchronously from the relevant actors.
<Candle>
As to why, a class has the option of being used in both a synchronous and asynchronous way, where as an actor has to be asynchronous.
<Candle>
(There are probably better answers from others in the channel though)
<svdvonde>
I should probably give some more context to understand the angle I'm coming from. The reason why I ask that specific question is because I'm investigating code reuse mechanisms for actor languages, and I'm looking for a convincing real-world use case that is currently difficult to develop using existing actor languages.
<svdvonde>
One avenue that I'm looking at is something that @SeanTAllen mentioned a while ago, related to code reuse mechanisms for actors: "There's no way to take something like TCPConnection and add additional functionality. More important, there's no way to take the notify class that specializes it and send it messages which is very limiting."
<svdvonde>
So I've been pondering about what he said and I'm wondering what the issue here is. In the case of the TCPConnection actor I can imagine some applications might want to define a special MyTCPConnection actor that specialises TCPConnection in some ways but not others (which, IIRC, is currently not possible).
<svdvonde>
The same would be true for TCPConnectionNotify, where, if it would be defined as an actor, then application-code couldn't define some "MyTCPConnectionNotify" actor that specialises it. But that leaves me wondering why precisely it is limiting that currently instances of TCPConnectionNotify must be classes.
<svdvonde>
@SeanTAllen perhaps you can clarify a couple of things for me?
svdvonde_ has joined #ponylang
svdvonde has quit [Ping timeout: 256 seconds]
svdvonde has joined #ponylang
svdvonde_ has quit [Ping timeout: 256 seconds]
<emilbayes>
What's the difference between `String.trim` and `String.trim_in_place`? `trim_in_place` seems to mention a `slice` method that doesn't exist anymore?
<emilbayes>
Ah, so `trim_in_place` seems to suggest that the `String` is mutated, while `trim` returns a new `String` but with the same underlying memory?