<snusnu>
that's an initial cleanup using the new Identity node (previously available as Noop, but unknown to me ;)
<dkubb>
snusnu: I wonder if Ducktrap::Node::Primitive.new(type) can return Ducktrap::Node::Identity.instance when the type is an Object
<dkubb>
snusnu: what I was hoping to do was remove the distinction between Typed and Untyped from the mapper. everything is typed, only some are more precise than Object
snusnu1 has joined #rom-rb
snusnu has quit [Ping timeout: 264 seconds]
snusnu1 has quit [Client Quit]
irclogger__ has joined #rom-rb
bf4 has joined #rom-rb
irclogger__ has quit [Ping timeout: 240 seconds]
bf4 has quit [Ping timeout: 264 seconds]
snusnu has joined #rom-rb
<snusnu>
dkubb: btw, current mutant report for the ducktrap branch
<dkubb>
snusnu: oh heh, so the integration test covers most of the conditions
snusnu1 has joined #rom-rb
snusnu has quit [Ping timeout: 245 seconds]
snusnu1 has quit [Quit: Leaving.]
snusnu has joined #rom-rb
<snusnu>
dkubb: heh, just noticed now that you actually replied already in irc, my connection is a bit flaky, so i only saw it when looking at irclogs
<snusnu>
dkubb: with your latest irc comment, your latest GH comment makes more sense ;)
<snusnu>
dkubb: you know how i mean that don't you ;) .. i'm mainly referring to the fact that i haven't read your idea about moving stuff inside ducktrap, when i was answering your latest comment on GH
<snusnu>
dkubb: however, i still wonder wether your suggestion about making Ducktrap::Node::Primitive.new(type) return Identity.instance if type.equal?(Object) really is needed
<snusnu>
dkubb: that is not to say it'd do any harm
<snusnu>
dkubb: i'm just thinking, that really, at this level, we want to purposefully *omit* any typing hint, as the system isn't doing any type casting at this point (when used with the complete rom stack)
<snusnu>
dkubb: the casting would've been done *before* the data gets fed into relations (tuples)
<snusnu>
dkubb: so i'm wondering, if Undefined doesn't capture the intent and implementation better .. there IS NO TYPING INFO .. it's left out, undefined … the system just *maps* .. whatever the types
<snusnu>
dkubb: now if you use that rom-mapper *without* the rom stack, you'd be able to add type checks by passing the otherwise Undefined type parameter
<snusnu>
dkubb: also btw, just pushed a reek config cleanup, only IrresponsibleModule is left .. if i look at the actual config, i'm happy too ;)
zekefast has joined #rom-rb
irclogger__ has joined #rom-rb
bf4 has joined #rom-rb
<dkubb>
snusnu: everything is an Object (or rather BasicObject) so it's true of everything in ruby anyway. I can't think of any use case where it would make a difference to tell between Undefined and Object
<dkubb>
snusnu: what I would suggest is keeping things streamlined and simple, only adding conditional logic if there's a valid use case
bf4 has quit [Ping timeout: 246 seconds]
irclogger__ has quit [Ping timeout: 272 seconds]
<snusnu>
dkubb: thinking a bit more about it, i'm actually fine with that change, let's see what mbj will say (i doubt that he'll be opposed)
<snusnu>
dkubb: i still think Undefined captures the intent clearly, but i agree that Object would serve just as well in our case, especially given that is_a?(Object) is always true, and given that ducktrap will "optimize it away"
<snusnu>
dkubb: i guess i'm going to support mappers = ROM::Mapper::Registry.build { } too, where the block would capture mapping definitions
<snusnu>
dkubb: so that it won't be necessary to instantiate the ROM::Mapper::Mapping::Registry.new manually and then hand it on to ROM::Mapper::Registry.build(mappings)
<dkubb>
we should talk with mbj, but I'm leaning towards lobbying for support of: map :id, :city, :zip, <Optional Type>
<snusnu>
heh, well, you know my stance on that .. i'm not really opposed .. but, (to quote you) .. shouldn't we wait for a usecase?
<dkubb>
people who want to write them one per line still can. people who want to define a bunch of stuff in a compact way can too.. in rabl it's used
<snusnu>
i.e. until someones complains that it's missing?
<dkubb>
yeah yeah :P
<snusnu>
or are you complaining ;)
<dkubb>
I dunno, lemme see when I write my first mapper with this
<snusnu>
heh, fair enough
<snusnu>
dunno why, i just don't like the looks of that ...
<dkubb>
I tend to use attributes :id, city, zip .. rather than one per line
<dkubb>
but maybe because I like to follow the docs
<snusnu>
you know, with this kind of syntax, i *always* find it harder to decipher what's going on
<snusnu>
same goes for attr_reader and friends
<snusnu>
i always use multiple lines
<dkubb>
activerecord supports it for their validates() stuff
<snusnu>
gives me an immediate overview of how many properties are involved, etc
<dkubb>
I must admit that I still write one attribute per line
<snusnu>
yeah, me too, exclusively
<dkubb>
yeah
<dkubb>
I think you may be write too
<dkubb>
*right
<dkubb>
I guess if there's a ton of attributes it will "punish you" by making things look really verbose
<snusnu>
let's go without it for a while, and make people who vote to have it make a *good* point about it (and not be stubborn ourselves)
<dkubb>
while being able to define them in a compact way it could hide them
<snusnu>
hm, if there's a ton of attributes, i guess i'd still like to see them nicely aligned and highlighted, line by line, but really, it's a matter of taste i guess
<dkubb>
you really shouldn't have a ton of attributes in an object anyway
<snusnu>
right
<dkubb>
we should make stuff look ugly when you're doing it wrong
<snusnu>
also, what i find hard about this syntax, is that i can *never* decide how many to put on a single line, where to break them, etc
<dkubb>
ok, you convinced me
<dkubb>
does this new mapper stuff depend on anima?
<snusnu>
heh ok
<dkubb>
I mean, does it require the class author to use anima.. I don't mind if it uses anima internally
<snusnu>
actually, i think it doesn't
<dkubb>
IMHO, I would probably write that README using POROs
<dkubb>
like without anima. explicit #initialize, etc
<snusnu>
it uses ducktraps #anima_load method, but even that, actually only relies on the interface iirc
<snusnu>
it's actually what was previously the ObjectBuilder in solnic's code
<dkubb>
someone who knows anima can translate it, but someone who doesn't know it now has to learn anima before it makes sense
<snusnu>
it assumes #initialize takes a hash
<snusnu>
oh wait
<snusnu>
actually, it depends on anima
<snusnu>
the ducktrap node depends on anima
<dkubb>
I was just looking at the README
<snusnu>
(to get at the dump)
<dkubb>
is there a way it can be made not to require it?
<dkubb>
I don't know if we want to force one kind of object builder on people
<snusnu>
hm .. that'd require a standardized #attributes_hash i guess :/
<snusnu>
we definitely don't want to
<dkubb>
we could standardize on it having #to_hash
<snusnu>
(force one builder on everyone)
<dkubb>
or does it have stuff where it can get/set the ivar?
<dkubb>
like we used to do?
<snusnu>
yeah, solnic's code supports #allocate #instance_variable_set and #anima_like
<snusnu>
we should support all those eventually
<snusnu>
via ducktrap
<snusnu>
for #anima_load, we need to standardize on #attributes_hash, #to_hash or probably what is used most, out there
<dkubb>
#to_h is actually a ruby core/stdlib protocol
<dkubb>
so we could standardize on that
<snusnu>
i thought about that too .. can't wait to hear mbjs thoughts on "polluting" the instance tho ;)
<snusnu>
currently anima fetches stuff via a class method (called .anima)
<dkubb>
I don't like polluting much either, but I also don't like tight coupling to an object builder. I realize it was done that way in this spike in order to cut down the work so the core idea could be communicated and not get lost in the noise
<snusnu>
the "funny" thing is, i already patched my local anima clone to support #to_h (via including Anima::Utils, a module providing #to_h)
<dkubb>
heh
<snusnu>
that's for work, but yeah ;)
<snusnu>
iirc mbj wasn't opposed actually
<snusnu>
i guess that's the safest bet, making the object builder (current anima stuff) depend on #to_h
<snusnu>
for the other 2 types, we should add ducktrap nodes that do the same work
<dkubb>
yeah, and then expand it to support the other strategies
<snusnu>
then rom-mapper can switch nodes based on a configured strategy, just like solnic's mapper allowed to configure the Loader/Dumper class used
zekefast has quit [Ping timeout: 244 seconds]
CraigBuchek has joined #rom-rb
<snusnu>
dkubb: what would you call the module that provides #to_h for anima?
<snusnu>
dkubb: is Anima::ToH bad? ;)
<snusnu>
Anima::Utils (what i have in my app) is too broad
zekefast has joined #rom-rb
<snusnu>
dkubb: btw, i really like #wrap and #group as DSL names to "solve" the belongs_to/has_many "dilemma"
<snusnu>
dkubb: the layer our mapper is at, it doesn't make sense to declare those "things" as relationships .. it's only concerned with mapping an EV/EC .. and it's imo very intuitive to say my object *wraps* another one, and *groups* others
<snusnu>
dkubb: i highly doubt that we'll have to come up with "classic" relationship definitions anywhere else in our stack .. the schema will eventually allow you to define (FK)References in some way, but no #belongs_to or #has_many should be needed
<snusnu>
i never liked walking endless chains of relationships, just to get you at some specific data, it always made me model all relationships i could see, not thinking about wether i actually need them or not
<snusnu>
with rom, i imagine to setup a proper schema, of just the relations/views i need, and then having specific mappers for all kinds of relations i need to iterate over
<snusnu>
i fully imagine to have different sets of classes that model the same domain object in different scenarios … i don't like having declared attributes either nil or empty
CraigBuchek has quit [Quit: Leaving.]
irclogger__ has joined #rom-rb
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 252 seconds]
irclogger__ has quit [Ping timeout: 244 seconds]
irclogger__ has joined #rom-rb
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 245 seconds]
irclogger__ has quit [Ping timeout: 248 seconds]
<dkubb>
snusnu: I'm not sure what to call that module
<dkubb>
snusnu: I agree Utils is too broad, and ToH is just bad :)
<snusnu>
hehe
kapowaz has quit [Ping timeout: 264 seconds]
kapowaz has joined #rom-rb
zekefast has quit [Quit: Leaving.]
irclogger__ has joined #rom-rb
bf4 has joined #rom-rb
irclogger__ has quit [Ping timeout: 240 seconds]
bf4 has quit [Ping timeout: 245 seconds]
zekefast has joined #rom-rb
snusnu has quit [Quit: Leaving.]
zekefast has quit [Quit: Leaving.]
irclogger__ has joined #rom-rb
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 245 seconds]
irclogger__ has quit [Ping timeout: 252 seconds]
zekefast has joined #rom-rb
zekefast has quit [Client Quit]
bf4 has joined #rom-rb
irclogger__ has joined #rom-rb
bf4 has quit [Ping timeout: 252 seconds]
irclogger__ has quit [Ping timeout: 246 seconds]
zekefast has joined #rom-rb
bf4 has joined #rom-rb
irclogger__ has joined #rom-rb
zekefast has quit [Ping timeout: 245 seconds]
bf4 has quit [Ping timeout: 272 seconds]
irclogger__ has quit [Ping timeout: 264 seconds]
zekefast has joined #rom-rb
ezkl has joined #rom-rb
zekefast1 has joined #rom-rb
zekefast has quit [Ping timeout: 264 seconds]
irclogger__ has joined #rom-rb
bf4 has joined #rom-rb
irclogger__ has quit [Ping timeout: 245 seconds]
bf4 has quit [Ping timeout: 244 seconds]
v0n has quit [Ping timeout: 264 seconds]
irclogger__ has joined #rom-rb
bf4 has joined #rom-rb
zekefast1 has quit [Ping timeout: 245 seconds]
zekefast has joined #rom-rb
irclogger__ has quit [Ping timeout: 246 seconds]
bf4 has quit [Ping timeout: 246 seconds]
v0n has joined #rom-rb
mbj has joined #rom-rb
zekefast has quit [Ping timeout: 264 seconds]
zekefast has joined #rom-rb
kalleth_ is now known as kalleth
bf4 has joined #rom-rb
irclogger__ has joined #rom-rb
bf4 has quit [Ping timeout: 246 seconds]
irclogger__ has quit [Ping timeout: 248 seconds]
irclogger__ has joined #rom-rb
bf4 has joined #rom-rb
irclogger__ has quit [Ping timeout: 245 seconds]
bf4 has quit [Ping timeout: 246 seconds]
zekefast has quit [Ping timeout: 264 seconds]
erp-lsf has joined #rom-rb
<erp-lsf>
greetings.
<erp-lsf>
is there any documentation on rom-rb, except github's README?
zekefast has joined #rom-rb
<mbj>
erp-lsf: currently documentation is rare. We have good coverage with YARD docs.
<erp-lsf>
can you please give me a link to YARD documentation?
<mbj>
erp-lsf: that YARD documentation is *within* the code.
<mbj>
You should be able to checkout the code and run the yard tool to get an html browsable version.
<mbj>
I dunno if there is a current online version.
<mbj>
BTW, I typically prefer the code with docs. Dislike to browse code bases via compiled html.
<mbj>
So I'm not the best person to give pointers ,)
<erp-lsf>
Thanks, I'll try to navigate myself in it too. :)
zekefast has quit [Quit: Leaving.]
zekefast has joined #rom-rb
snusnu1 has joined #rom-rb
kleech has joined #rom-rb
bf4 has joined #rom-rb
irclogger__ has joined #rom-rb
zekefast has quit [Ping timeout: 246 seconds]
bf4 has quit [Ping timeout: 245 seconds]
irclogger__ has quit [Ping timeout: 244 seconds]
<snusnu1>
mbj: we need a generalized object builder in ducktrap, in fact we need 3 … one that does #allocate, one that uses #instance_variable_set .. and one (we *kinda* have now) that handles anima like objects
<snusnu1>
mbj: for the "dump" part, we should rely on #to_h
<snusnu1>
(for anima like, that is)
<snusnu1>
mbj: currently my mapper spike depends on anima, that's not good (enough)
<snusnu1>
mbj: dkubb and i were talking about #to_h yesterday, and agree that it's the way to go .. it's a "new" ruby convention
<snusnu1>
mbj: also, with #to_h support in ruby-2.0, i think it's fair enough to just include #to_h by default in anima
snusnu1 has quit [Quit: Leaving.]
snusnu has joined #rom-rb
<mbj>
snusnu: argreed
<mbj>
snusnu: BUT we need to make sure "extra" keys returned from #to_h do not get stripped unnoticed.
<snusnu>
extra keys?
<mbj>
snusnu: Nothing is more stupid than a typo getting "droppped".
<mbj>
snusnu: If an object returns a hash with unexpected keys.
<snusnu>
how would it do that?
<mbj>
snusnu: Murphy!
<mbj>
snusnu: BTW I cannot concentrate, clients time!
<mbj>
snusnu: laters! gonna go offline to focus
mbj has quit [Quit: leaving]
<snusnu>
lol, well, i was thinking #to_h would delegate to .anima.attributes_hash ?
zekefast has joined #rom-rb
snusnu has quit [Quit: Leaving.]
breakingthings has joined #rom-rb
erp-lsf has quit [Ping timeout: 250 seconds]
bf4 has joined #rom-rb
irclogger__ has joined #rom-rb
CraigBuchek has joined #rom-rb
irclogger__ has quit [Ping timeout: 240 seconds]
bf4 has quit [Ping timeout: 248 seconds]
CraigBuchek has quit [Quit: Leaving.]
cored has joined #rom-rb
cored has joined #rom-rb
jgaskins has joined #rom-rb
CraigBuchek has joined #rom-rb
bf4 has joined #rom-rb
irclogger__ has joined #rom-rb
bf4 has quit [Ping timeout: 246 seconds]
irclogger__ has quit [Ping timeout: 245 seconds]
kleech has quit [Remote host closed the connection]
kleech has joined #rom-rb
kleech has quit [Ping timeout: 264 seconds]
kleech has joined #rom-rb
CraigBuchek has quit [Quit: Leaving.]
CraigBuchek has joined #rom-rb
bf4 has joined #rom-rb
irclogger__ has joined #rom-rb
irclogger__ has quit [Ping timeout: 246 seconds]
bf4 has quit [Ping timeout: 264 seconds]
zekefast has quit [Quit: Leaving.]
jgaskins has quit [Quit: This computer has gone to sleep]
jgaskins has joined #rom-rb
bf4 has joined #rom-rb
irclogger__ has joined #rom-rb
irclogger__ has quit [Remote host closed the connection]
irclogger__ has joined #rom-rb
v0n has left #rom-rb ["WeeChat 0.4.2"]
irclogger__ has quit [Remote host closed the connection]
irclogger__ has joined #rom-rb
vsorlov has joined #rom-rb
irclogger__ has quit [Remote host closed the connection]
irclogger__ has joined #rom-rb
irclogger__ has quit [Remote host closed the connection]
irclogger__ has joined #rom-rb
snusnu has joined #rom-rb
irclogger__ has quit [Remote host closed the connection]
irclogger__ has joined #rom-rb
snusnu has quit [Quit: Leaving.]
kleech has quit [Remote host closed the connection]
kleech has joined #rom-rb
irclogger__ has quit [Remote host closed the connection]
irclogger__ has joined #rom-rb
<dkubb>
good morning
kleech has quit [Remote host closed the connection]
kleech has joined #rom-rb
kleech has quit [Ping timeout: 245 seconds]
<vsorlov>
hi
snusnu has joined #rom-rb
CraigBuchek has quit [Quit: Leaving.]
dkubb|away has joined #rom-rb
dkubb has quit [Ping timeout: 264 seconds]
dkubb has joined #rom-rb
dkubb|away has quit [Read error: Connection reset by peer]
<cored>
mbj: it was nice, well meeting people that I follow was the best part
snusnu1 has quit [Quit: Leaving.]
<cored>
there were some good talks too
<mbj>
cored: Ping me if you find another interesting conf ;)
<cored>
I'm testing with mechanize now because I tried a lot with faraday/nokogiri without success
<mbj>
cored: I still need "hints" :D
snusnu has joined #rom-rb
<cored>
mbj: sure, I'm planning on going to Ancient Ruby
<mbj>
cored: Where is your *exact* problem with mechanize?
<snusnu>
mbj: shall we add #to_h to anima proper?
<mbj>
snusnu: okay. I dont like all #to_foo methods. But this one seems tobe okay.
<snusnu>
mbj: i know, and i don't like them either, the thing is, #anima_load could and should be generic and independent from anima .. but it needs to rely on getting at the hash representation of an object
<dkubb>
cored: I would suggest using Addressable::URI and #query_values= to setup the query string. string concatenation will fall down if any of the values need escaping
<snusnu>
mbj: basically, anima_load is the ObjectBuilder strategy in solnic's code
<snusnu>
mbj: and since with ruby-2.0, #to_h became an official convention, it might be best to rely on that
<mbj>
snusnu: Fine with me.
<cored>
dkubb: in which part in particular? probably you saw the build_url thingy which I'm not using at the moment. Becase right now I'm using mechanize, that was for the faraday test that I did which was also using URI.encode
<snusnu>
mbj: ok cool, i'll do the patches, most probably for ducktrap too
<snusnu>
mbj: btw, no pressure, but do you have a rough eta for morpher?
<snusnu>
mbj: just wondering, if it's necessary to still do ducktrap patches
<mbj>
snusnu: I'm commercially busy.
<mbj>
Just need to start.
<mbj>
I expect 4-5 hours of concentrated work will finish it.
<snusnu>
shall i call you on skype and you just do it on the side? we'll do that a few days in a row and it's done done?
<snusnu>
:p
<snusnu>
srsly tho, i can wait 4-5h
<snusnu>
:p
<mbj>
snusnu: Heh, would work.
<mbj>
snusnu: I try to work "good" when there is antoher code on the side. Just beeing silent and listening to what I tell him why I'm doing my job.
<snusnu>
2nd line needs an lvar to support the closure, 3rd line wouldn't
<snusnu>
mbj: ^^
<mbj>
snusnu: dunno
<mbj>
snusnu: 2nd!
<snusnu>
i prefer 3rd
vsorlov has quit [Read error: Operation timed out]
<mbj>
snusnu: 3rd is more nodes when represented as AST.
<snusnu>
ok? why's that
<mbj>
snusnu: both are 6 nodes.
<mbj>
snusnu: BUT self.class.constructor is 3 level chaining.
<mbj>
snusnu: And include constructor is not.
<mbj>
snusnu: 3 level chaining reminds me of LOD violation.
<snusnu>
whatever that matters ...
<snusnu>
srsly?
<snusnu>
when accessing a class method?
<snusnu>
...
CraigBuchek has joined #rom-rb
<mbj>
snusnu: For me these are *all* objects.
<snusnu>
mbj: dude, there's an otherwise completely useless lvar assignment that needs the very same 3 level chaining
<mbj>
hehe
<snusnu>
now, i wouldn't have asked if i were decided already ;) but yeah, i notice that i lean towards relying on the private send, given that it's *so* common anyways
postmodern has joined #rom-rb
<snusnu>
mbj: btw, anima master has 2 spec failures!
<snusnu>
warrgh and since an anonyomous class#name is nil, i can't just change the subject to be Class.new(described_class) … because you use self.class.name.split inside Error#initialize
<snusnu>
tbh, i find those overwritten exception classes weird
<dkubb>
I would use class_eval, since send(:include) is using a private method.. albiet one that is a common part of the API, but it's still private
<snusnu>
and it inherits from RuntimeError? shouldn't that maybe be StandardError?
<snusnu>
dkubb: i agree in principle
<dkubb>
for me send() is an absolute last resort. if there's a way to get around it I usually try to
<snusnu>
dkubb: the one liner would read nicer tho ;)
<snusnu>
normally yes, but with #include .. it could be argued that it really probably is here to stay
<dkubb>
I think include is going to be made public in ruby 2.1
<snusnu>
it'd be nice for sure
<dkubb>
like extend
<snusnu>
yeah
breakingthings has quit [Ping timeout: 246 seconds]
breakingthings has joined #rom-rb
vsorlov has joined #rom-rb
vsorlov has quit [Ping timeout: 264 seconds]
<snusnu>
mbj: can you please add me to anima on GH?
<mbj>
snusnu: you have commit rights for ages!
<snusnu>
mbj: why can't i push then?
<snusnu>
tbh, i'm confused too
<mbj>
snusnu: public remote?
<mbj>
snusnu: use the git remote!
<mbj>
snusnu: the git+ssh remote ;)
<snusnu>
ssh: connect to host github.com port 22: Connection refused
<snusnu>
fatal: Could not read from remote repository.
<snusnu>
and the repository exists.
<snusnu>
Please make sure you have the correct access rights
<mbj>
github has tmp problems than.
<mbj>
connection refused!
<snusnu>
ok sry, got confused
<snusnu>
seems like pull isn't working either, so yeha
<snusnu>
btw, i fixed the spec failures in anima, and added the constructor feature
<snusnu>
but there's other mutants alive, that i'm not in the mood to tackle right now
<snusnu>
the actual commit for supporting super, didn't get discovered by mutant anyway, but i added a spec nevertheless
<snusnu>
mbj, dkubb: btw, using an lvar plus class_eval vs. a private send makes for 6 points difference in flay score