unbalancedparen has quit [Read error: Connection reset by peer]
unbalancedparen has joined #ponylang
jemc has joined #ponylang
<TwoNotes>
Is that the backpressure that was in TCPConnection before, or is this a new hting?
jemc has quit [Ping timeout: 260 seconds]
<TwoNotes>
Can see light at end of tunnel regarding HTTP update for streaming.
jmiven has quit [Quit: co'o]
jmiven has joined #ponylang
amclain has quit [Quit: Leaving]
_whitelogger has joined #ponylang
Matthias247 has joined #ponylang
_andre has joined #ponylang
mrkishi has joined #ponylang
CcxWrk has quit [Ping timeout: 268 seconds]
CcxWrk has joined #ponylang
Praetonus has joined #ponylang
Matthias247 has quit [Read error: Connection reset by peer]
jemc has joined #ponylang
<TwoNotes>
I try to call a behavior in an iso class, declared 'fun iso apply'. ponyc complains the receiver is an iso!. Does calling a function count as making an alias?
<Praetonus>
Yes
<TwoNotes>
But if I make it 'fun val apply' then apply can not modify any state.
<TwoNotes>
Oh, my question was, does calling a function count as making an alias of the *receiver*?
<TwoNotes>
I know it makes an alias of the parameters
<TwoNotes>
Hmm. So I can't treat a notification class as an iso.
<TwoNotes>
I will try as a ref then.
<doublec>
TwoNotes: this is why in the http code you see (consume request).respond(...) type code
<doublec>
TwoNotes: the request is an iso so you need to consume it when calling a function
amclain has joined #ponylang
<TwoNotes>
The trouble is, in this case, that the receiver is a persistent field in the calling actor. It gets used several times
<TwoNotes>
Changing it to a ref seems to work. I have arranged that it only exists within one actor
<TwoNotes>
So the caller, rather than passing in a Notification handler, passes in a 'factory' class. The factory gets called from within the actor and the resulting notification object lives in there, and can be a ref
<TwoNotes>
This allows the notification object to have its own internal state that can be modified
<TwoNotes>
In particular, it can create its own "back end" processing actor
<doublec>
TwoNotes: couldn't the caller pass in an iso notification handler and the actor then consume it to a ref?
<doublec>
TwoNotes: to avoid the factor
<doublec>
s/factor/factory/
<TwoNotes>
hmm.
<TwoNotes>
The application code does not know when the package will need another handler. In the case of an HTTP server, a handler has to be created for each incoming connection.
<TwoNotes>
So I have the application pass in an object which can then create clones of the handler as required. That is the factory
<doublec>
ok
<TwoNotes>
Since an HTTP server can be handling many connections at once, each needs its own handler to properly track the state of the protocol
Matthias247 has joined #ponylang
jemc has quit [Quit: WeeChat 1.4]
jemc has joined #ponylang
_andre has quit [Quit: leaving]
felko has joined #ponylang
<felko>
I have a design question about Pony
<felko>
Why did you choose to put trait implementation at the definition of the type ?
<felko>
Whereas you could gain in flexibility and readability by separating these, like in Haskell or Rust
<felko>
You currently solve most of these problems with interfaces, but what if the name of the implemented function differs from the one in the interface ?
<felko>
e.g. `getName` instead of `name`
<felko>
Ok I got it, this system doesn't work in Pony because you have private members, so you'd have to know the internal structure of the class to implement a trait
<SeanTAllen>
@TwoNotes i dont believe you need a factory for that
<SeanTAllen>
felko: welcome!
<felko>
thanks
<SeanTAllen>
Why did you choose to put trait implementation at the definition of the type ? <-- not sure what you mean
<SeanTAllen>
also not sure what this mean... "Ok I got it, this system doesn't work in Pony because you have private members, so you'd have to know the internal structure of the class to implement a trait"
<SeanTAllen>
The only difference between a trait and an interface is that interfaces are structural subtyping and traits are nominal
<SeanTAllen>
Thus the trait being class Foo is SomeTrait
<SeanTAllen>
and the compiler will verify that nominal typing
<SeanTAllen>
you can do that with an interface as well but it isnt required
<felko>
I was wondering why you didn't choose to implement traits in a different statement than class definition, like in Rust where you have the impl statement, totally disconnected from the struct statement
<felko>
because that allows us to work with types that are not defined in our code (so we can't modify their implementation)
<felko>
this system works in Rust and Haskell because structs are transparent, whereas Pony's classes are not
<felko>
because if we want to define the implementation of a trait for a type that is not defined in our code, then we'll probably have to manipulate private members, which we don't want
jemc has quit [Ping timeout: 258 seconds]
<SeanTAllen>
I dont understand the last statement felko
<SeanTAllen>
At the moment, pony requires access to the source in order to do its whole program optimization
<SeanTAllen>
Sp there is no "access to the type but not the implementation"
<felko>
Maybe an example would help
<SeanTAllen>
what do you mean by "private member" when you refer to traits felko? methods? fields?
<SeanTAllen>
an example of what?
<felko>
of the problem raised by not separating functions from trait implementation
<felko>
imagine we have a ToJSON trait
<felko>
if would have a fun toJSON(): JSON function
<SeanTAllen>
ok
<felko>
if we want to implement ToJSON for classes we don't have access to, what should we do
<felko>
?
<SeanTAllen>
i dont understand "dont have access to"
<SeanTAllen>
pony requires all source to be available at compilation time
<felko>
like, a class that is defined in an external library
<SeanTAllen>
so there is no "dont have access to"
<felko>
we only have access to the private members of a class if the class is defined in the same module right ?
<SeanTAllen>
same package yes.
<felko>
yes, sorry
<felko>
so, what if we want to implement ToJSON for a class that is defined in another package ?
<felko>
i'm really new to Pony, I started to read the docs a few hours ago, sorry if my question is stupid
<SeanTAllen>
see line 11?
<felko>
yes
<SeanTAllen>
it implements an interface defined in another package
<SeanTAllen>
same thing on line 35
<SeanTAllen>
because the interface is public
<felko>
yes, but my problem is the other way around, what if the class is defined in another package, not the interface
<SeanTAllen>
as are its required methods
<SeanTAllen>
i dont understand
<SeanTAllen>
the class is defined in that example in a different package from the interface
<SeanTAllen>
Main, Listener and Server are all classes/actors defined in a package different from the two interfaces that Listener and Server implement
<felko>
lets say you are developping a web framework
<SeanTAllen>
I need to leave in 10 minutes, so I might disappear on you...
<SeanTAllen>
Ok I'm developing a web framework
<felko>
in the standard library, there is a wsgi package
<SeanTAllen>
I make the source of that framework available
<felko>
implementing a basic wsgi server
<SeanTAllen>
and you can include it in your PONYPATH and it will be compiled into your program
<felko>
lets say you also have a cgi package in the standard library
<felko>
and you want to "unify" them in your web framework
<SeanTAllen>
i dont know that "unify" means
<felko>
because they have a different interface
Matthias247 has quit [Read error: Connection reset by peer]
<felko>
like, the cgi server may have a run function, and the wsgi have a start function
<felko>
but they are doing the same thing
<SeanTAllen>
ok
<SeanTAllen>
im not sure why i want or need to do that
<SeanTAllen>
or what it has to do with traits
<felko>
so you want them to have the same interface, so that the user of your framework can switch from one server to another
<felko>
without changing every run into start
<felko>
(for example)
<SeanTAllen>
the OO approach is the adapter pattern
<SeanTAllen>
but again, i dont know what this has to do with traits
<felko>
the problem is that i'm thinking to much haskell
<felko>
ad in haskell you would solve this with typeclasses, which look like traits but aren't
<SeanTAllen>
traits are definitely not typeclasses
<SeanTAllen>
if you think of them as typeclasses, you'll end up in trouble
<SeanTAllen>
traits are traits as defined in the traits papers
<felko>
not in Pony, but in Rust they are almost the same, so i think i mixed everything
<SeanTAllen>
scala has mixins that it calls traits but they aren't traits as defined in the traits papers
<SeanTAllen>
i havent used rust in a while and dont remember the details of their traits implementation. i see to remember them being actual traits though.
<felko>
Pony's traits are like Java/C# interface ?
<SeanTAllen>
no
<felko>
:(
<SeanTAllen>
they are like traits
<SeanTAllen>
there are similiarities
<SeanTAllen>
but they aren't the same
<felko>
i guess i'll read traits papers
<SeanTAllen>
they are close but there are differences
<SeanTAllen>
traits and interfaces in pony are basically the same, except one is nominal typing, the other structural. anyway, i have to run. if you have more questions ask away here or on the mailing list and someone, if not me, can answer