solnic has quit [Read error: Connection reset by peer]
jlee- has joined #rom-rb
jlee- has left #rom-rb [#rom-rb]
solnic has joined #rom-rb
postmodern has quit [Ping timeout: 256 seconds]
splattael has joined #rom-rb
<solnic>
dkubb: morning. still there?
lorenzo_ has joined #rom-rb
snusnu has joined #rom-rb
<solnic>
snusnu: morning
zekefast has joined #rom-rb
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
<snusnu>
solnic: yo
<solnic>
snusnu: hai
<solnic>
snusnu: this relation/mapper split feels extremely good
<snusnu>
solnic: yeah, with our current knowledge, i'm pretty sure that it's the correct way forward
<solnic>
snusnu: it is
<solnic>
snusnu: I'll push 0.0.1 once I get this in-memory adapter working + basic mapping
<solnic>
snusnu: man, I'm so happy with the rename
<snusnu>
solnic: heh, the in memory adapter, as you said, it's a matter of storing the updated relations back in a hash
<snusnu>
solnic: i have no idea why i thought it's working already back then
<snusnu>
solnic: most likely cause i could get the specs to pass
<snusnu>
solnic: then again those specs must've been broken anyway :p
<solnic>
snusnu: yes they were
<solnic>
but that's ok
<solnic>
we got them nuked
<solnic>
:D
<snusnu>
nice
<snusnu>
heh
<snusnu>
solnic: so, now that we've split things up, do you think we should somewhat agree on who's working on what?
<solnic>
snusnu: so yeah, we need a gateway that would handle the inmemory persistence
<solnic>
snusnu: yeah sure I'd love to split the work somehow
<snusnu>
solnic: i could put my focus on the relation graph if that's alright with you?
<solnic>
snusnu: there's very little work that is needed to get basic relation/mapper released
<solnic>
snusnu: I was going to suggest that you could improve the join strategy thing
<solnic>
I'll add the simple dsl so that setup is easy
<solnic>
but it won't touch relationships
<snusnu>
solnic: yeah, for that, i need some quality time with dkubb at least, mbj might be helpful too
<solnic>
so feel free to work on that
<solnic>
snusnu: I can suggest a couple of things from the top of my head
<snusnu>
please do
<solnic>
first one - injecting classes == evil
<snusnu>
full ack
<solnic>
I've stopped doing that, it's never a good idea
<snusnu>
instances ftw
<solnic>
osm :)
<solnic>
totally
<solnic>
second, I forgot
<solnic>
lol
<snusnu>
heh
<solnic>
I'll look at this code again
<solnic>
snusnu: btw I introduced concord in rom-relation
<snusnu>
i saw that, nice"
<solnic>
I'm still on the fence with this gem though
<snusnu>
it's a really nice little idiom imo
<solnic>
it gives very little imho, esp that I need to override "new" to inject default objects
<snusnu>
it's a one liner that communicates important aspects, reducing otherwise necessary boilerplate
<solnic>
it could at least support that
<snusnu>
if you need to do that, don't use concord
<solnic>
why? I think I have a need for a DI lib like dependor, which I mentioned already
<snusnu>
imo the "gain" with concord is that i can assume a number of things about a class if i see it being included
<snusnu>
default args in constructors isn't one of those things
<snusnu>
imo that's too much
<solnic>
well, that is true
<solnic>
that's why I said I think I need a DI lib :)
<snusnu>
i'm not sure, initially i was on the fence with concord too, mbj remembers … but imo it's just fine grained enough to be really useful, while not hiding complexity (because it doesn't introduce any)
<solnic>
I'm not against it
<solnic>
it's useful
<snusnu>
i'd vote for implementing DI manually, and only go for further abstractions if we *really* find a need
<snusnu>
that's what i love about concord, understanding it takes you ~1min
<snusnu>
dependor, dunno … but longer
<snusnu>
solnic: btw, re default values in #initialize .. i have this feeling, and it's only a feeling, that they shouldn't be used too much .. can't explain properly, i can only say that i actually needed that very rarely
<solnic>
snusnu: got the same feeling
<solnic>
if you want defaults, those should leave in an outer layer, a bit higher than the constructor
<snusnu>
solnic: maybe the "coerce layer" helped … if there's something outside of the instance, that makes sure that input is properly coerced, #initialize itself can have a tight interface, and only assign to ivars .. making concord the right choice oftentimes
<snusnu>
right!
<solnic>
s/leave/live/
<solnic>
full ack :)
<snusnu>
solnic: imo default values are just a hidden if/else .. once you introduce them, you have more codepaths .. and lots of codepaths in #initialize seem wrong, better move them somewhere else (where they're most probably more explicit)
<solnic>
snusnu: yes, that's very true
<solnic>
snusnu: btw I'll be giving a presentation about immutable ruby objects at today's local ruby group meetup
<solnic>
should be fun
<snusnu>
solnic: nice! you should link me to the slides once you have them online somewhere
<solnic>
snusnu: it will be boring for you
<solnic>
snusnu: it's gonna be recorded so you could watch (maybe a bit less boring)
<dkubb>
I'd rather kill PRs or merge them early vs than keep them hanging around in limbo (assuming the PR actually does something and isn't half-working)
kapowaz has quit [Ping timeout: 246 seconds]
stormwin1 has quit [Ping timeout: 246 seconds]
lorenzo_ has quit [Quit: leaving]
<mbj>
dkubb: I dont see any reason for streaming.
<mbj>
dkubb: But from code I'd merge that feature.
<mbj>
dkubb: I like the indentation, so we have an improvement. Lets merge it.
<zekefast>
mbj, snusnu: For di there is a couple frameworks.
<mbj>
zekefast: I think I'm to dump, I do never understand why DI needs a framework ;)
<mbj>
zekefast: For mee this is DI, foo(bar), bar is the injected dependency :D
<mbj>
zekefast: Pls help me to remove my confusion.
<zekefast>
first one is Needle. Looks powefull, I used it for implement core of my application which inject logger and configuration into proper components (in fact settings into the rom-rb).
<zekefast>
Second one is dim by Jim Weirich
<zekefast>
And packaged to the gem by someone else
<zekefast>
by the way it's a good presentation from JIm if you haven't seen it on DI containers.
<zekefast>
mbj, Ok, I wan't really accurate in the term. IoC containers
<dkubb>
mbj: ok, I've merged that code into master
<mbj>
zekefast: sync, now I get the point ;)
<mbj>
dkubb: nice!
<dkubb>
mbj: for me the main benefit is that it uses ruby conventions for appending.. streaming is a nice side benefit
<zekefast>
In fact, DI refer to the Dependency Injection pattern and DIP to Dependency Inversion Principle from B.Martin. So mbj, you notice closure to principle implementation.
<dkubb>
mbj: although, as you know, I'm a big believer in using constraints to help shape my design and I think being forced to think of the output as write-only allows us to do things we couldn't if we assumed it was a String
<mbj>
dkubb: I'm okay with this change. Dont really had strong opinions against or for.
<mbj>
dkubb: Yeah, especially that detect newline via last chunk is nice!
<zekefast>
Yeah, And don't read DHH's article about DI, it's holly crap IMO.
<mbj>
zekefast: I like to read other opinions
<mbj>
zekefast: Especially if they are not in sync with mine
<snusnu>
zekefast: i dunno about any DI frameworks, which makes me think i don't need them
<dkubb>
I think DHH has a pretty good sense for interface design, but I pretty much disagree with almost all of his articles about software
<zekefast>
mbj, then you can find a long long tail to the DHH aticle in blogs around there which agreed and disagreed with DHH point, but they mostly near useless as DHH's one.
<mbj>
hehe
<mbj>
I think I opened dhh's article once, but did not finished reading
<dkubb>
I've joked before that if you do the exact opposite of whatever he says you'll get some pretty good results ;)
<zekefast>
Sure in dynamic languages much can be simplified, but you get to the right direction.
<zekefast>
dkubb, Almost agree with you :)
<dkubb>
I'm partly kidding
<zekefast>
dkubb, play-doh is cool it's predecessor of Needle I suppose.
<dkubb>
mbj: on the subject of streaming. I tried an experiment to add a Stream subclass to represent a Newline, then I could have the Stream object be immutable, and I'd have different classes represent the state of the stream. However, I couldn't get it to work properly
<dkubb>
mbj: I may try again at some point
<zekefast>
I'm not, I haven't feel solid with his ideas on software design.
<snusnu>
dkubb: hey, can i pick your brain for a minute wrt axiom evaluator context and rom relation?
<dkubb>
snusnu: sure
djsell has quit [Quit: Leaving.]
<snusnu>
dkubb: my initial thought was that in order to be able to reference object land attribute names, we could inject a customized evaluator concept into axiom relations, that handles the translation of object land attribute names to relation land attribute names
<snusnu>
dkubb: thoughts?
<snusnu>
dkubb: since a rom relation knows about the axiom relation and the mapper, that translation should be possible
<snusnu>
dkubb: i'm obviously talking about axiom relation methods that accept a block
<dkubb>
snusnu: I suppose if we had a default object that just does a pass-through of the attribute (i.e. no translation) it could work
<dkubb>
snusnu: did you want to open a PR on axiom with some changes so we can discuss it there? I
<dkubb>
I'm open to discussing some code
<dkubb>
snusnu: summary, extend, order, restrict would be obvious candidates. my only concern is with cluttering the interfaces too much
<snusnu>
dkubb: ok, i'll try to come up with something in the next few days, i'm pretty busy unfortunately, so i just wanted to drop the idea in order to know if you have any reasons against it
<dkubb>
snusnu: another option would be something like: relation.restrict(&BlockTranslatorObject.new(block))
<dkubb>
obviously the name should be something nicer than that ;)
<snusnu>
dkubb: right, that's basically what i was about to suggest
<snusnu>
dkubb: so, i'm wondering, what did you think i was saying? ;)
<dkubb>
snusnu: yeah. What I was thinking you were talking about is something like: relation.restrict(translator) { ... }
<dkubb>
snusnu: which would probably clutter the interface with extra options that are only sometimes used.. to me that's a bit of a smell
<snusnu>
dkubb: ah ok, but no, i was actually thinking of injecting a customized context from within ROM::Relation, pretty much like you outlined
<dkubb>
snusnu: wrapping the block in something that maps the block onto something that the axiom relation needs is great
<snusnu>
dkubb: yeah, i believe it's a pretty straight forward way to do the translation, without affecting/having to change any axiom code
<snusnu>
dkubb: axiom would only ever see relation land attribute names
<dkubb>
that's good. you want the axiom code to be as dumb as possible
<snusnu>
right
<dkubb>
such a "block mapper" done right would allow you, in theory, to map to any kind of relation
<dkubb>
even if you were crazy enough to be wrapping a ROM::Relation
<snusnu>
do you see usecases for that?
<dkubb>
no
<snusnu>
ok good :)
<dkubb>
I just like the idea of thinking about interfaces, not necessarily object types
<dkubb>
a ROM::Relation is virtually indistinguishable from an Axiom::Relation at the interface level, which is as it should be
<dkubb>
if they do deviate I think that would be a problem
<dkubb>
if we add convenience methods to ROM::Relation to make some kinds of queries easier, we should consider pushing those down to the Axiom::Relation
<snusnu>
yeah, there should be no difference, apart from the fact that a rom relation yields objects, and that attributes should be accessible via object land names
<snusnu>
yeah
<dkubb>
I purposefully designed the Axiom::Relation interface to be relatively bare bones. I didn't want to add a ton of convenience methods to it until they had been implemented and tested at higher layers. once they have proven themselves I would push them down
<snusnu>
that's the right thing to do
<dkubb>
ok, I'm going to get to work now, will bbl
<dkubb>
mbj: I hope to do more work on sql.rb tonight. if you want, feel free to add some TODO notes on what's next. I can work on it a bit tonight and tomorrow night