<mbj>
dkubb: I think it should be "prior knowlege" if an object is a tuple or a primitive.
<mbj>
dkubb: I begun mbj/predicates that should be able to define predicates on POROs via an intermediate AST representation.
<mbj>
dkubb: I'll have special nodes that access an object attribute to reuse predicate on primitives.
<mbj>
dkubb: This is somehow that stuff we planned for axiom-logic.
<mbj>
dkubb: I'll happily move the code to axiom-logic, but for now I'm "freeing" myself from thinking about axiom. To learn how to implement these thing AST backed.
<mbj>
dkubb: Where ducktrap will not evaluate and gracefully exit if the input format does not match expectation mbj/predicate will run into errors.
<mbj>
dkubb: *excetpions
<dkubb>
I could make it so there are literal containers that respond to #call
<dkubb>
the main reason for those is to handle literals
<mbj>
Yeah
<dkubb>
btw, I will be out for a tiny bit, but we can chat afterwards
<dkubb>
the only reason I didn't to it is I was trying to minimize object creation
<mbj>
I think it will be possible to do this without containers.
<mbj>
Lemme try ;)
<dkubb>
but it would be nice to do the literal conditional at the front-end of the interface, and then remove this extract_value from everywhere in the code
<mbj>
foo.bar if foo.respond_to?(:bar) makes me nervous always.
<mbj>
Its okay for DSL / setup code.
<mbj>
But not for the "hot path".
<dkubb>
I don't mind as long as there's an else condition
<mbj>
heh
<dkubb>
I try not to return nil though
<mbj>
Just lemme try for myself to run into all problems of that domain.
<dkubb>
nil is often the worst return value from a method
<dkubb>
k, go for it
<mbj>
+1
<mbj>
Its best to try for yourself to understand a problem.
<mbj>
And to question design decisions with a good foundation.
kleech has quit [Remote host closed the connection]
postmodern has joined #rom-rb
gildo has quit [Ping timeout: 252 seconds]
mbj has quit [Ping timeout: 272 seconds]
snusnu1 has joined #rom-rb
zekefast has quit [Quit: Leaving.]
zekefast has joined #rom-rb
zekefast has quit [Client Quit]
snusnu1 has quit [Quit: Leaving.]
kleech has joined #rom-rb
snusnu has joined #rom-rb
kleech has quit [Remote host closed the connection]
<elskwid>
mbj: Hey, just wanted to say, I saw your comment about bundler + rubygems, before you go off and build a new thing you should check in with Evan Phoenix and the rubygems team. Your concerns are not unique.
<elskwid>
I'm sure they could use the help.
mbj has quit [Ping timeout: 246 seconds]
mbj has joined #rom-rb
<mbj>
elskwid: Yeah, I'll probably do this.
<mbj>
elskwid: But I need to fail on myself first ;)
<elskwid>
mbj: Learning from their failures and potentially magnifying the adoption of your solutions might be worth joining sooner rather than later.
<elskwid>
mbj: I had just seen @brixen mention he was thinking of rewriting and Evan asked to talk to him about it. I know many people are unhappy. The collective is stronger ... :-)
mbj has quit [Ping timeout: 272 seconds]
zekefast has quit [Quit: Leaving.]
mbj has joined #rom-rb
<mbj>
elskwid: I'd love a rubygems replacement build on top of the ROM foundation, adamantium, equalizer, ...
<mbj>
elskwid: And it should be mutation covered ;)
<elskwid>
mbj: Can't argue with the mutation coverage. Pretty sure the goals of "rubygems" is, you don't need gems to get other gems. ha ha.
zekefast has joined #rom-rb
<elskwid>
mbj: I was only making sure you had some names and ideas that people were working on it and that they would probably be so very happy with your help.
<mbj>
elskwid: I'm dropping from the channel due poor cellphone coverage, but I read the messages on logger ;)
<mbj>
elskwid: Yeah, I'll join them once I have the time.
<elskwid>
okay. Sorry about the coverage!
<mbj>
elskwid: But let me try for myself, an initial spike.
zekefast has quit [Client Quit]
zekefast has joined #rom-rb
knowtheory has quit [Quit: Computer has gone to sleep]