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
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 quit [Quit: Leaving.]
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
irclogger__ has quit [Remote host closed the connection]
irclogger__ has joined #rom-rb
mkristian 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
dkubb has joined #rom-rb
<snusnu>
hey dkubb
vsorlov has joined #rom-rb
<mbj>
dkubb: hola!
<snusnu>
dkubb: here's a spike for the ducktrap based mapper i was talking about (it works): http://pastie.org/8472423
<snusnu>
dkubb: a rough integration spec is at the bottom
mkristian has quit [Ping timeout: 245 seconds]
<dkubb>
snusnu: mbj: good morning
<snusnu>
dkubb: in case you have time to look at the spike (or at least the spec) .. if you're interested why i support "untyped primitive" mapping, i'm happy to discuss it
<dkubb>
snusnu: typing shouldn't be necessary imho
<snusnu>
exactly
<snusnu>
the schema definition should take care of it
<snusnu>
when used with the rom stack, the mapper shouldn't perform extra type checking
<snusnu>
but it still needs the type "hints" for EV/EC
<dkubb>
yeah, the only reason you might augment it with typing is maybe if you're wanting to eliminate the explicit schema and do an Active Record-like 1:1 mapping, and infer the schema from the mapping
<dkubb>
but I wouldn't want that in the *core* mapper stuff
<snusnu>
exactly my thinking
<snusnu>
with ducktrap, it boils down to removing the #primitive check inside #fetch_key block
<dkubb>
what I want to do at some point is infer some types from the existing schema to build up the base schema
<snusnu>
yeah
<snusnu>
there's a few other differences to the current rom-mapper … solnic's version adds additional API needed for session, like Mapper#identity_from_{tuple, object}, Mapper#call (which renames the relation), Mapper#new_object and Mapper#model … i'm not sure those are needed, or rather, if the mapper is the right place to put them
<snusnu>
i'm going for Mapper#{load, dump} for now .. that's all it needs for mapping
<dkubb>
my rule of thumb with builder methods is that the method should derive more of the information from "itself" than from it's arguments
<dkubb>
if it ends up using the arguments a ton, then maybe the method shoudl be moved to one of the objects or their classes
<mbj>
Guys I'd love to join you in discussion. Still have clients issues. back later ;)
<snusnu>
dkubb: are you hinting at some specific code in the builders in my spike?
<dkubb>
no
<dkubb>
I was just commenting on you saying there was Mapper#new_object, etc
<snusnu>
ah ok, i see
<dkubb>
I haven't looked over the spike enough
<snusnu>
no worries, i just needed some context here ;)
<dkubb>
snusnu: for Registry#each, do you need to iterate over the key/value pairs, or could you just use entries.each_value ?
<snusnu>
dkubb: yeah, both works i guess, #each_value would be enough i guess
<dkubb>
I need to extract the options stuff from axiom-types
<snusnu>
the model is contained in mapping
<dkubb>
then methods that are returning "static" values, could be declared as an option
<dkubb>
snusnu: one other approach could be, instead of having Undefined, define a top-level "Object" type. everything should match it. you may be able to remove some conditional logic
<dkubb>
then everything is typed, some are just strong and some are really weak
<dkubb>
maybe have a transformer that does nothing except passes through the object
bf4 has joined #rom-rb
<dkubb>
snusnu: this is really nice and clean. I can't claim to understand it completely, but I can see some of the ideas
<dkubb>
snusnu: it feels like the more we iterate the simpler the implementations get ;)
<snusnu>
heh thx, and yes, i have the same feeling
<snusnu>
there's a little bit of terminology mixup (in my head at least) that i'm not yet happy with entirely … actually, the only thing the conditional is for, is to avoid a *type check* that ducktrap does … that's for primitives .. it doesn't actually do conversion … with EV/EC tho .. it's used "later on" .. for #anima_load .. so it kinda *is* a type cast .. no check
<snusnu>
dunno, that may sound confusing ...
<snusnu>
and yes, re your suggestion about the generic Object type .. i like the idea, but i still need to fit it into the above described problem
<snusnu>
dkubb: i'm gonna split it into separate files later today evening, and then push it to a branch in rom-mapper, do a PR, so that we have a place to discuss
<dkubb>
yeah, I mean, I don't understand the whole thing.. I did see #typed?, which led me to believe there's a conditional somewhere, and I just figured if you had some base class that essentially represents "no type" then maybe it's possible to treat everything with the same code path
<dkubb>
I wonder if Ducktrap has an "identity function" that doesn't do anything other than pass the value through
<snusnu>
right now, when the type is omitted in the DSL, it's set to Undefined, and there's a Attribute::Simple and a Attribute::Simple::Typed builder .. the typed one, adds the primitive *check*, the Simple one doesn't
<snusnu>
so that's kinda dirty
<snusnu>
not sure about that identity, if it doesn't, it probably should have one
<dkubb>
I always figured that "map :id" would be equivalent to "map :id, Object"
<dkubb>
I also wonder if we should allow multiple attribute names, eg: map :id, :city, :zip ?
<snusnu>
well, it's a bit different with ducktrap … basically, in the current spike .. map :id means, do nothing, just map … map :id, Integer means … map, but check if we have an Integer
<snusnu>
dkubb: the latter suggestion for multiple attrs, it could be done, but i don't like it .. mostly based on visual preference tho
<dkubb>
yeah, I was saying that it should check to see if it's an Object (rather BasicObject), which would always be true of course
<snusnu>
yeah, i get it .. but it could be argued, that it should do no check .. well, a passthrough would kinda imply that . but with ducktrap, it boils down to adding or not adding a "transformation node" . and that transformatio node, actually doesn't transform . but check … that's the dirty part i mean
<dkubb>
I'm not sure if I dislike it purely because it's visually harder to read, or if it's due to being more familiar to the DM1, virtus and other apis we've done
<snusnu>
same here
<dkubb>
snusnu: yeah, well, I think it wouldn't *need* to do any check. it could just return true or whatever.. because we know every object has to be a kind of BasicObject. I was more thinking about that approach to just eliminate one place for a conditional
<snusnu>
yeah, i've been doing that with other conditionals (like, letting the Attribute definition know about its builder class)
<dkubb>
I liked that
<dkubb>
could those methods be moved up to class methods, since they always return the same value?
<snusnu>
the other point, is more about me not knowing/understanding ducktrap enough just yet … i don't know the line between *checks* and *transforms*
<snusnu>
maybe mbj can help with that
<dkubb>
I mean, because they don't use instance state
<snusnu>
yeah, i thought about that … with class methods, it's always a thin line imo … allowing instance independent methods to be instance methods and *private* .. sometimes seems cleaner than making them class methods, but public
<dkubb>
I'm sure mbj will agree that there are some times you just need a default transformation that is a no-op.. that you'd use as a placeholder in some cases
<snusnu>
i guess so, yes
<dkubb>
I wish an instance could access it's own private class methods
<snusnu>
yeah, that'd be cool
<dkubb>
ok, I've got to run for a bit. I'll stay in the channel, but I'll keep irc backgrounded and check it every once in a while
<snusnu>
sweet, maybe i'll ping you in a few hours then
jgaskins has quit [Quit: This computer has gone to sleep]
jgaskins has joined #rom-rb
zekefast has joined #rom-rb
Eiam has joined #rom-rb
mkristian has joined #rom-rb
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
mkristian has quit [Ping timeout: 252 seconds]
zekefast has quit [Quit: Leaving.]
zekefast has joined #rom-rb
mkristian has joined #rom-rb
zekefast has quit [Ping timeout: 244 seconds]
vsorlov has quit [Ping timeout: 272 seconds]
zekefast has joined #rom-rb
zekefast has quit [Client Quit]
zekefast has joined #rom-rb
zekefast has quit [Client Quit]
CraigBuchek has quit [Quit: CraigBuchek]
mkristian has quit [Quit: bye]
CraigBuchek has joined #rom-rb
snusnu has quit [Quit: Leaving.]
CraigBuchek has quit [Quit: CraigBuchek]
jgaskins has quit [Quit: This computer has gone to sleep]
CraigBuchek has joined #rom-rb
CraigBuchek has quit [Quit: CraigBuchek]
zekefast has joined #rom-rb
breakingthings has quit []
CraigBuchek has joined #rom-rb
CraigBuchek has quit [Client Quit]
bf4 has quit [Ping timeout: 240 seconds]
irclogger__ has quit [Ping timeout: 245 seconds]
dkubb-ircloud has quit [Quit: Connection closed for inactivity]