<harber>
so i'm attempting to make an (extremely juvenile) muxer to slap on top of http for my basic uses. I'm still very new to pony, and the paradigms aren't in my head yet. I know there isn't a such thing as, like, function pointers. My first thought is that i'd make a sort of "controller" interface that i can pass classes into the muxer to be served the request object, but now I think that would only create 1 version of each controller
<harber>
what's the best practice for something like that, where i'd need the http handler to spin up a class based on the route, and the classes would be supplied up front. lambdas?
<jemc>
harber: can you show what you have so far?
<harber>
probably. it's not worth looking at, probably, but i can show my randomass pokings ;)
<jemc>
in general, I think what you probably want is an `interface HTTPHandler` that defines what the handler class needs to implement
<jemc>
if the `interface` contains only an `apply` method, then that could optionally be fulfilled by a lambda, since a lambda is an instance of an anonymous class or primitive that has an `apply` method with the signature of the lambda
<jemc>
if you need more methods than just `apply`, or if you want a different name for it, then the library user would fulfill that with either an object literal or a named class/primitive
<jemc>
you'd approach something similar to the "notify object" pattern used by classes like `TCPConnection` and `TCPConnectionNotify`
<harber>
i was just trying to figure out how a pony actor/class would be able to ingest and store a function for later use, without the concept of function pointers
<harber>
that gist is just ramblings around trying to create that sort of interface
<jemc>
so, "ingest and store a function for later use" sounds like partial application
<jemc>
which is another way to create lambdas / object literals from a method that takes args that you don't want to supply yet
<jemc>
not quite - I was still trying to pull up the link :D
<vaninwagen>
We both shot him, that is what counts
<harber>
lol
<harber>
it's true, aim all the bullets at me
<harber>
i didn't catch this whole partial application methodology before
<vaninwagen>
harber partial application is also just a syntactically very nice way to create an interface with an apply method and the expected arguments and return types
<jemc>
it's worth noting that partial application is just sugar for creating an object that knows how to call that method later
<vaninwagen>
So, my best guess is, your handlers for http requests should be classes or objects, rather than functions
<vaninwagen>
With a proper interface to them, you gonna build your own gatling gun
<harber>
yeah, that's what i would have liked, but how can i register a "class" for later use, i guess, was my question. so i could match against the route and know which class to create at that time
<harber>
i didn't want to create a giant matcher that creates the class i need inline
<harber>
so like, in another language i might create a map to types, or function pointers, and create a type at that point
<vaninwagen>
Ah ok. And you want a new instance for every request?
<harber>
wouldn't that be better? or i'd end up with a single instance and concurrency goes down the tubes?
<harber>
also my first actor model ;)
<harber>
so i'm well out of my depth here
<vaninwagen>
So, every tcp-connection is handled by a single actor. Every http request is handled within that actor, but can be passed off to another one for processing
<harber>
yeah, i followed that part
<vaninwagen>
You can share a class amongst actors if it is immutable (val), so you would actually have no bottleneck
<vaninwagen>
But it makes it hard to keep state
<harber>
oh, interesting. so if the class isn't actually storing state, and i'm using it as a function container of sorts, it actually would be concurrent?
<vaninwagen>
So 1 instance per http-session or -request makes sense, but you could also pass some object as another argument to your handler (maybe as iso) that carries session/request scoped state
<vaninwagen>
harber yes that is the case
<harber>
i was gonna' worry about actually passing around the request after i'd found a real pattern for this
<vaninwagen>
Think of classes as being used inside actors and passed between them. But what you execute, what is doing things, are sctors. The main entities in your program.
<harber>
if i make a class in an actor somewhere, and i pass that little guy around to a bunch of other actors as read-only, it's essentially just pass by reference, right?
<vaninwagen>
You could either put a factory primitive or class to you muxer. A thingy that knows how to create handler instances, and already has all the necessary arguments from outside (e.g. the Env or so)
<SeanTAllen>
"We both shot him, that is what counts" <-- I'm dying
<vaninwagen>
That would be my approach
<harber>
i think a factory primitive is what i was looking for
<harber>
and didn't know how to go about that
<vaninwagen>
Shooting people on irc, the only place where that shit is legal
<vaninwagen>
It also does http routing, but needs some love
<harber>
ah yeah, i probably should have looked through jennet first. forgot it existed. i ran across it weeks ago when i first looked at the concept and forgot to star it. thanks for the heads up ;)
<harber>
so poking through jennet shows i was on a similar thought pattern and would have likely come to a solution ;) good to know.
<harber>
i was worried i was just going to pile of anti-patterns
Foaly has quit [Quit: Now 'mid shadows deep falls blessed sleep.]