<snusnu>
mbj: i just saw you mentioning your plans to release concord 1.0 soonish .. do you think concord would benefit from including #initialize via a module?
<snusnu>
i think we already had this discussion at some point, i don't remember the outcome tho ;)
<mbj>
snusnu: I'd love to support passing arguments to super on Concord infected classes.
<mbj>
snusnu: I think thats a feature that should be in 1.0
<mbj>
snusnu: Can you open an issue, so I dont forget it?
<mbj>
snusnu: I talked to Dan, and there will be an equalizer 1.0 release "soon" also.
<snusnu>
mbj: thing is, i often use self.new for that cause, and oftentimes it seems the most clean thing to do anyway (like, providing default values for some args) .. however, there are situations (even if rare) where you might want to perform additional work in #initialize itself
<mbj>
I'd love concord depends on that one.
<mbj>
snusnu: I currently do this via: class Foo; include Concord.new(:bar); def initialize(bar) @bar = bar; work; end; end
<mbj>
So I *still* get some benefit out of concord (Equalizer, and attr_readers)
<mbj>
But I agree, calling super (actually zsuper) would be handy.
<snusnu>
i see, but it feels a bit weird, having to "reimplement" #initialize
<snusnu>
yeah
<mbj>
snusnu: I'd accept that feature if you PR it. But please open an issue.
<snusnu>
mbj: re the rename from cookie to majoun, i'm not completely against calling it cookie (i agree it's not the exact same thing as with datamapper, cookie is no pattern) .. but yeah, majoun happens to be an awesome name too :p
<mbj>
snusnu: If you change the gem.name, you should IMO also change the top level namespace.
<snusnu>
yeah, i had no time for that tho, and also, i wouldn't really like that … maybe i'll switch back to cookie at some point, but not now
<snusnu>
btw, you might have noticed that i sent a PR for mbj/response too, integrating it with cookie stuff
<mbj>
snusnu: Yeah. Still had no time to look into it.
<snusnu>
no worries ..
<mbj>
snusnu: Did some unparser mutant bug hunting yesterday (addictive!)
<snusnu>
heh
<snusnu>
out of curiosity, how long does the corpus spec run?
<mbj>
Which one?
<mbj>
the unparser one is pretty fast
<mbj>
The mutant corpus is very slow.
<mbj>
Unparser sucks at bigger ASTs
<mbj>
Because I did some nasty backtracing
<mbj>
foo = bar if foo vs if foo; foo = bar; end
<mbj>
In the first one foo is an lvar read in condition, in the 2nd one foo is a private send.ö
<mbj>
So I need to scan up the AST to find foo is an lvar (or not) and if it just was introduced to emit the guard form.
<mbj>
And I redo that scanning up, without any caching.
<mbj>
Lots of room for improvement.
<mbj>
Each parent node could / should cache the current lvar scope.
<mbj>
But for now I do several thousand scans of the parents for lvars on each potential case of foo = bar if foo vs if foo; foo = bar; end
<mkristian>
hi, a quick question: I upgraded Virtus-0.5.5 and everything works. but when I follow the deprecated warning and switch to Virtus.model things fail
snusnu has quit [Quit: Leaving.]
mkristian has quit [Remote host closed the connection]
jordanyee has quit [Quit: MacBook went to sleep.]
cored has quit [Ping timeout: 240 seconds]
cored has joined #rom-rb
mkristian has joined #rom-rb
mkristian1 has joined #rom-rb
mkristian has quit [Remote host closed the connection]
<CraigBuchek>
mkristian1: More details? What's failing? What error messages?
<mkristian1>
CraigBuchek: there I really need to dig a bit deeper. haven't done it yet - give me some time.
<mbj>
CraigBuchek: I think resting for Virtus module as ancestor was never part of the intended public API
<mbj>
CraigBuchek: s/resting/testing/ ;)
<mbj>
CraigBuchek: If you want to test if a given class is "virtus infected" you should probably test for Virtus::Model, I do not know how future compatible this is.
<mbj>
CraigBuchek: Also I'd ask myself, if such a test should actually be needed? Reflections like this are IMO a sign of a smell.
<CraigBuchek>
mkristian1: Why do you need it to be === Virtus?
<mbj>
CraigBuchek: sorry I wanted to addres mkristian1 ;)
<mkristian1>
CraigBuchek: I have a visitor which goes over the object tree to serialize it, so I need to distinguish between Array, Hash, Virtus and 'primitives'
therabidbanana has joined #rom-rb
<mbj>
mkristian1: All I posted above to CraigBuchek was targeted on your person ;)
<mkristian1>
mbj: yes I got it . . . ;)
<CraigBuchek>
LOL. mbj, I wasn't paying attention and thought that was still mkristian1 talking.
<mkristian1>
but replied to wrong person now ;)
<mbj>
hehe
<mkristian1>
mbj: if Virtus::Model works that is OK to me
<mbj>
mkristian1: Maybe you should ask yourself why there is no prior knowlege in your controlflow about the type of the argument.
<mkristian1>
mbj: so Virtus::Model does not work :(
jordanyee has joined #rom-rb
<mkristian1>
mbj: I iterate over all attributes and need different behaviour depending on the type
<mbj>
mkristian1: Why do you need to do this recursive?
<mbj>
mkristian1: The root (that contains primitives) is always a virtus model?
<mbj>
mkristian1: So a virtus model (in your case) never contains a virtus model?
<mbj>
Than you could remove that inline signalling.
<mbj>
mkristian1: You could look into object.class.ancestors if you find anything significant there.
<mbj>
I'm not familiar with the virtus code base.
<mkristian1>
mbj: there are about 50 model objects which use Virtus models all over the place. never mind, I just create an empty base class as "identifier" for my purpose
<mbj>
mkristian1: Heh I see, not easy to differenciate the control flow to avoid "snooping" the type. You could just test for a domain specific module you include to your virtus models.
<mbj>
mkristian1: For all such cases I typically prefer having an explicit type list, not testing for something like ::Virtus (::Virtus::Model), I'd register the types where I setup the classes (Or on your case register via an encluded hook of YourLib::Serializable)
<mbj>
mkristian1: Because not everything that includes ::Virtus (::Virtus::Model, or whatever virtus specific API you test for) is meant to be serialized.
robmiller has joined #rom-rb
<mbj>
mkristian1: So I'd co for a dedicated ::YourModel::Serializable mixin you use for signalling (or registration).
<mbj>
mkristian1: One thing, I notice your library does not have a root namespace. I'd change this to avoid naming conflicts.
<mkristian1>
mbj: I see you point and I will go for some Marker module. yes, since I am about to change things it is the right time to add a namespace to model (all other files do have a namespace)
<mkristian1>
mbj: thanx for all your input !
skade has quit [Quit: Computer has gone to sleep.]
sferik has joined #rom-rb
sferik has quit [Ping timeout: 252 seconds]
vsorlov has joined #rom-rb
jordanyee has quit [Quit: MacBook went to sleep.]
CraigBuchek has quit [Quit: Leaving.]
bestie has quit [Quit: bestie]
vsorlov has quit [Read error: Operation timed out]
solnic has joined #rom-rb
<solnic>
mkristian1: YourModelModule = Virtus.model and then include this in your classes, which btw is how I'd like people to use Virtus :)
<mkristian1>
solnic: not completely clear. ```include Virtus.model``` is not the right thing to do ?
<solnic>
mkristian1: it is, but this way every class includes a new module, you can generate it once and store under your own constant
<mkristian1>
solnic: cool - now I got the point ;)
<solnic>
yeah I never communicated this clearlly
<solnic>
Virtus.model *builds* a module instance for you
<solnic>
and you can configure this module
cored has quit [Ping timeout: 255 seconds]
<solnic>
Virtus.model(coerce: false) and you've got a module with coercions turned off
<solnic>
etc
<mkristian1>
solnic: hey I use virtus for a long time BUT only today I started with version 1.0.x
cored has joined #rom-rb
<solnic>
mkristian1: yeah it has some new features
<solnic>
mkristian1: wait for 2.0 now that will be awesome ;)
<mkristian1>
solnic: first I want to use all those nice features from 1.0.x ;)
<mkristian1>
I am a bit slow in picking up new things sometimes . . .
cored has quit [Ping timeout: 240 seconds]
<mbj>
solnic: What exactly are you planning for 2.x ?
<mbj>
solnic: I know there is a backend change you planned ;) but what else?
cored has joined #rom-rb
<solnic>
mbj: strip down the interface
<solnic>
I mean, parts of the interface
<solnic>
esp when it comes to determining types
<solnic>
this shit is awful right now
<solnic>
I pretty much kept it just because I didn't want to break people apps too much with 1.0.0
mkristian1 has quit [Ping timeout: 252 seconds]
<solnic>
but mostly it'll be anima + morpher with some DSL sitting in front that matches more or less what we have now in Virtus
<mbj>
solnic: makes sense.
<mbj>
solnic: Will you somehow allow to plug morphers into attributes / full model?
<solnic>
mbj: yeah I'm hoping to do that
<mbj>
solnic: We still need to add coerctions to morpher that are transtive and optionally many times more strict than the onces in coercible.
<mbj>
solnic: Either we write a morpher-coercible shipping these as pure morpher nodes or just ship them with morpher.
<solnic>
well, I'll start my work on virtus 2.0 by refactoring coercible completely
<mbj>
solnic: Feel free to ping me on a pairing, so we end up in deduplicated work.
<mbj>
I still think morpher should support strong / weak coercions.
<solnic>
or maybe even replace coercible with morpher?
<mbj>
Morpher currently handles the non primitive datastructure coercions, I should be easy to add support for the primitives.
<mbj>
Yeah, that was my point.
<mbj>
Morpher should substitute coercible.
<mbj>
It should consume its features.
<mbj>
Also you get evaluation tree support for leaves that could not be coerced: Big win for reporting / debugging.
<solnic>
otoh a pure primitive coercion lib can be useful in other contexts
<solnic>
we'll see
<mbj>
solnic: Sure.
<mbj>
Whatever we end up should have an api to get a clean error state.
<mbj>
And hte primitives in the replacements should be wrappable in a morpher node.