endformationage has quit [Ping timeout: 245 seconds]
christianpoveda has quit [Quit: Connection closed for inactivity]
brainproxy has quit [Ping timeout: 246 seconds]
brainproxy has joined #ponylang
brainproxy has quit [Ping timeout: 252 seconds]
acarrico has joined #ponylang
svdvonde has joined #ponylang
<svdvonde>
I am wondering out of general interest. Pony is an active-object actor language, and active object languages usually have an "active layer" (of active objects) and "passive layer" of plain old objects. Does pony offer any built-in active object classes? Or perhaps through libraries? If so, when do you make the trade-off between offering some functionality as an
<svdvonde>
Woops, pressed enter too soon. To rephrase the last sentence: If so, how does one make the trade-off between offering some functionality as an active object class (to create actors) or as a regular class?
<svdvonde>
Let me clarify what I mean. At some point an application programmer (or library programmer) will have to make the conscious decision to expose something either as an actor or as a class. Switching from one to the other afterwards is non-trivial. I might be thinking in way too abstract terms, but I am wondering what that conscious decision would be based on.
<Candle>
svdvonde: So your 'passive layer' are things like val classes? your 'active layer' are both actors and mutable classes?
<Candle>
So far I have aimed to expose data structures as classes with the actors using them being part of the application.
<Candle>
svdvonde: Rephrasing the question: "How do you decide if a 'thing' should be an actor or a class?" ?
<svdvonde>
Yes, exactly
<svdvonde>
If I am not mistaken, Pony supports a large number of actors, so it would be beneficial to use them in a fine-grained manner -- so applications that run using many actors, rather than an application consisting of only a handful of actors. So then it would make sense to offer some code (e.g. code in a library) as an actor class rather than a regular class. I am wondering how someone decides on one or the other.
<svdvonde>
When the application concern being implemented by the class should run concurrently to all other concerns, then the question is easily answered. Likewise if this particular application concern involves any form of tolerance to failures (e.g. which would be a crashing actor -- can be detected via monitoring etc.)
<svdvonde>
Perhaps I am thinking about this way too abstractly
<svdvonde>
Still, though... The brief conversation yesterday with SeanTAllen got me interested. What is the rationale behind offering "net/TCPConnection" from the stdlib as an actor rather than a class? https://stdlib.ponylang.org/net--index
<Candle>
I would say that's because you want linear access to the connection; using an actor in this case forces that interaction.
<Candle>
Having multiple actors or threads writing or writing to the same tcp connection is going to cause some 'entertaining' bugs.
<Candle>
er, reading or writing
<svdvonde>
Fair enough. Hmmm I need to think about this some more before I can explain myself properly.
svdvonde has quit [Quit: Page closed]
<_andre>
when using the FFI and the C function blocks, is it possible and/or necessary to inform the pony runtime about it?