solnic changed the topic of #rom-rb to: Ruby Object Mapper | Mailing List: https://groups.google.com/forum/?fromgroups#!forum/rom-rb | Logs: http://irclog.whitequark.org/rom-rb
V8Energy has joined #rom-rb
knowtheory has quit [Quit: Computer has gone to sleep]
postmodern has joined #rom-rb
dkubb has joined #rom-rb
snusnu has quit [Ping timeout: 245 seconds]
snusnu has joined #rom-rb
jfredett has joined #rom-rb
jfredett has quit [Quit: Leaving.]
jfredett has joined #rom-rb
jfredett has quit [Client Quit]
postmodern has quit [Quit: Leaving]
dkubb has quit [Quit: Linkinus - http://linkinus.com]
V8Energy has quit [Ping timeout: 245 seconds]
mbj has joined #rom-rb
mbj has quit [Quit: leaving]
mbj has joined #rom-rb
<snusnu> yo mbj
<snusnu> mbj: i looked through anima's code and i see nothing that would enable the anima.extend(:bar) feature you were talking about recently (for adding attributes in subclasses)
<mbj> snusnu: lulz, sorry so this is an addition to anima in one of my projects.
<snusnu> mbj: heh thought so, mind pushing it up to anima?
<mbj> snusnu: mom
<snusnu> thx!
<mbj> snusnu: Lets find a better name than extend
<mbj> snusnu: Dislike to clash with Object#exted
<mbj> snusnu: Anima#add ?
<mbj> snusnu: Anima#append
jfredett has joined #rom-rb
<mbj> snusnu: Anima#add !
<mbj> snusnu: We can also have Anima#remove
jfredett has quit [Quit: Leaving.]
knowtheory has joined #rom-rb
knowtheory has quit [Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/]
<snusnu> mbj: Anima#inherit ?
<snusnu> mbj: Anima#merge ?
<snusnu> forget #merge
<snusnu> mbj: i guess i like Anima#add
<snusnu> mbj: not sure about the implications of #remove, feels a bit non-inheritance'ish .. LSP wise
<snusnu> mbj: i guess we should hold off implementing #remove .. i can't think of a usecase, you obviously didn't need it either so far, so yeah ..
<snusnu> mbj: or are you thinking about non-"classic"inheritance usecases, more in the direction of prototypical inheritance support
<mbj> snusnu: Just adding #remove for the sake of symetric api
<mbj> snusnu: Also maye a inherited class does compute a given attribute
<snusnu> mbj: ok fair enough
<mbj> snusnu: close to finish it
<snusnu> sweet
<mbj> snusnu: It feels so good to do quality coding in an environment that honors it
<snusnu> heh, true
<mbj> snusnu: Just pushed the changes
<mbj> snusnu: Pls review, and in case you like them, I'll release anima-0.1.0
<snusnu> mbj: lol dude you're going too far with ast design (naming): "Emit Anima#{remove,add} support ..."
<mbj> snusnu: haha
<mbj> snusnu: Yeah just saw it :D
<snusnu> ;)
<snusnu> mbj: but yeah, looks good :) … i left a tiny comment
<mbj> snusnu: fixed, do a last pass pls.
<snusnu> mbj: when inheriting from a class, does the new #initialize call the superclass constructor?
<snusnu> mbj: this could be replaces with concord: https://github.com/mbj/anima/blob/master/lib/anima/attribute.rb#L94
<snusnu> mbj: and if you don't want that, you should still move the method to the top of the class in the public section
<mbj> snusnu: yeah, its old code
<mbj> snusnu: I think I'll not use concord here.
<mbj> snusnu: Anima and concord should not depend on each other
<snusnu> mbj: ok
<snusnu> mbj: what about the super calling?
<snusnu> mbj: should it even be done?
<snusnu> mbj: also, you know what i'd do with https://github.com/mbj/anima/blob/master/lib/anima/attribute.rb#L68-L71, right?
<snusnu> mbj: no strong feelings of course ..
<snusnu> mbj: but in this case it would also make using concord "impossible" thus not surprising that it's not being used
<snusnu> mbj: also, it'd save loc
<mbj> snusnu: pls elaborate a bit
<mbj> snusnu: Dont get your thoughts fully (undershugared)
<snusnu> mbj: if you do @instance_variable_name = :"@#{name}" in #initialize and add an attr_reader, you'd save loc
<mbj> snusnu: I like to see the definition of the semantics of a public interface right a long its definition.
<mbj> snusnu: Attribute#instance_variable_name is public interface.
<mbj> snusnu: An attr_reader would let me "search through the class" where the corresponding ivar might be written (okay this is probably the initializer in our style :D)
<snusnu> mbj: i don't get all this memoized methods (if they are unlikely to be overwritten) … i prefer an object to be complete once #initialize is done …
<snusnu> mbj: it's a matter of style tho, as i said, i don't have strong feelings about this one
<mbj> snusnu: I'd love ruby would provide something like an immutable method
<mbj> snusnu: as a buildin!
<snusnu> mbj: i can see your reasoning, so everything's fine with me .. just told you my thoughts :)
<mbj> snusnu: class Foo; fun; expression; end; end
<mbj> snusnu: sure
<mbj> snusnu: I'd love to patch in "fun" :D
<mbj> snusnu: Maybe I'll make a lib for "functions"
<mbj> snusnu: using memoizer internally
<mbj> class Foo
<mbj> include Function
<mbj> fun do |bar|
<mbj> expression
<mbj> end
<mbj> end
<mbj> But that would create a closure
<mbj> that library should be called "fun" :D
<mbj> 0.5k downloads since 2012 :(
<mbj> no gh activity for 11month
<snusnu> why not build on top of it?
<mbj> of tht fun lib?
<mbj> see the code...
<snusnu> yeah, why not
<mbj> snusnu: You wanna me build on that code? https://github.com/grsmv/fun/blob/master/lib/fun/functional.rb
<mbj> snusnu: totally not my style :D
<snusnu> well then you have to find another name :)
<mbj> snusnu: FYI released as anima-0.1.0
<snusnu> awesome, thx!
<mbj> snusnu: I added you solnic and dkubb to anima
<mbj> snusnu: So you can do the changes in need.
<mbj> snusnu: same with concord seconds ago
<snusnu> thx
<mbj> reboot after kernel update
<mbj> back soon (hopefully)
mbj has quit [Quit: leaving]
mbj has joined #rom-rb
<mbj> Back inline in 3-5 hours
<mbj> s/inline/online/
<mbj> going out for weekend-family-activity
<mbj> snusnu: Read your mail and accept you need a gplus account :D
mbj has quit [Quit: leaving]
<snusnu> i won't join gplus
V8Energy has joined #rom-rb
<solnic> snusnu: dude, you need a google account to use hangouts, no need to have a g+ account
<solnic> they merged gtalk with hangouts
<snusnu> solnic: not sure if that allows group video calls
<snusnu> solnic: just activated it and it said that i should get a g+ account because among others, that allows video group chat with up to 10 people
<solnic> snusnu: shit, ok then Skype :P
jfredett has joined #rom-rb
jfredett has quit [Quit: Leaving.]
mbj has joined #rom-rb
mbj_ has joined #rom-rb
mbj_ has quit [Client Quit]
<mbj> snusnu: Im searching a better name for the pice inside of mutant that identifies subjects to mutate
<mbj> snusnu: Its is currently called "matcher"
<mbj> snusnu: But IMHO this is "arbitrary" naming
<Gibheer> mbj: infecter?
<Gibheer> or TestSubjectSearcher
<Gibheer> or just Igor, as the small helper of Dr. Frankenstein, who had to get all parts for the tests ;)
<mbj> Gibheer: lulz
<mbj> Gibheer: infecter does not "search"
<mbj> Gibheer: And "Igor" is for the "too initiated" :D
<Gibheer> you just have to document good enough ;)
<mbj> Gibheer: haha
<Gibheer> a little tale for a class would be a pretty fun to read :D
<mbj> Gibheer: BTW you infected my families mind, after we meat you at eurucamp we cannot say "Gib her" anymore.
<Gibheer> haha
<mbj> Gibheer: I have to say "gib es mir" or something, but "gib her" is now fundamentally broken in my german.
<Gibheer> I'm sorry? ;P
<Gibheer> mbj: how about Marker?
<mbj> Gibheer: Best suggestion so far
<mbj> Gibheer: But it IMHO does not really mirror the "finding" aspect.
<Gibheer> what does that class do? hold a list of subjects to mutate?
<mbj> Gibheer: it FINDS the subjects
<Gibheer> and if it found them, what then?
<mbj> Gibheer: they get mutated :)
<mbj> Gibheer: There are many strategies with finding subjects
<mbj> Gibheer: just start with a namespace like ::Foo
<mbj> Gibheer: Or find a specific Method like ::Foo#bar
<mbj> Gibheer: you know that syntaxes from the CLI
<Gibheer> yeah
<Gibheer> so it could be called a Selector or Finder?
<mbj> yo
<Gibheer> or Scout
<mbj> Scout for mutation hunting!
<snusnu> mbj: what namespace is the matcher in?
<snusnu> mbj: maybe Mutant::Subject::{Matcher, Identifier} would fit
<mbj> snusnu: Mutant::Matcher
<mbj> snusnu: I'll not put it inside the Subject namespace
<snusnu> why?
<mbj> snusnu: The matcher is "free standing"
<mbj> snusnu: It produces subjects
<snusnu> so?
<mbj> snusnu: And there is no real reason to place it into the Subject namespace
<snusnu> apart from it being *very* obvious what it does?
<mbj> snusnu: good point
<snusnu> you literally described it as thing identifiying subjects
<mbj> snusnu: but its lots of code, and it will grow a lot
<snusnu> so?
<mbj> snusnu: hah :D
<mbj> snusnu: I'll use the "scope" name
<snusnu> i srsly want to know your reasoning, not trying to box through my suggestion ;) it's just that i haven't heard what i'd consider arguments against it so far ;)
<mbj> snusnu: ähm "Scout"
<snusnu> in the context of programming, i immediately know what a Mutant::Subject::Matcher does … granted, Mutant::Scout isn't bad either, but i happen to prefer the former ;)
<mbj> snusnu: I dislike deep nesting
<snusnu> i like good naming
<snusnu> :p
<mbj> Good single name > good only in nested context name
<snusnu> true
<snusnu> i dunno, for some reason, i like "generic" concept to repeat their names across projects … a matcher is something familiar to a programmer, scout is fitting, i won't deny that, but it'll take me a bit longer to get it
<snusnu> also, i don't have a real problem with nesting as long as it stays within sensible bounds .. and we're talking *one* level difference here
<snusnu> really tho, i like Scout too, it's just that Subject::Matcher was the very obvious thing to suggest, based on your description
<solnic> gaaah
<mbj> snusnu: heh
<solnic> spent entire day poking around virtus codebase
<mbj> snusnu: I was unhappy with matcher for some time
<mbj> snusnu: So I'll name it scout
<solnic> and realized I want to go back to previous design with some small tweaks
<snusnu> heh
<mbj> solnic: heh, that happened to me so often :D
<snusnu> ain't that a good thing then?
<solnic> sorry for interrupting so abruptly
<solnic> I realized what I did added so much complexity
<solnic> I think it’s good
<solnic> I’m gonna use modules…to extend attribute instance after it was initialised…because that’s the simplest thing that can work :P
<solnic> I went down the typical OOP road with composition
<solnic> and it SUCKS
<snusnu> mbj: btw, not specifically for this case, but in general .. i explicitly try to remind myself to hold off with cool names, i want boring names, i want names to repeat themselves on different levels, this surfaces similarities
<snusnu> solnic: you shouldn't do things that suck, they suck
<snusnu> :p
<mbj> snusnu: You make me think harder about the work I did in the last 5min :D
<solnic> it’s funny because there’s one thing that made me realize current design sucks
<solnic> I ended up with Attribute class being anemic
<solnic> it does literally NOTHING right now
<mbj> solnic: "round trip design"
<solnic> with axiom-types integration a lot of stuff goes away from virtus
<solnic> so Attribute feels completely empty right now
<snusnu> solnic: some things don't do anything, they just encapsulate data, just sayin ...
<solnic> snusnu: it’s not the case here
<solnic> right now Attribute delegates everything to its collabolators
<solnic> it has no behaviour at all
<mbj> solnic: Axiom types has a nice surface, but I dislike it builds times from inheritance. Talked with dkubb multiple times about this and currently it is the most simple implementation that works. (sidenote)
<solnic> mbj: yeah I think we need instance-based types btw
<solnic> I’m allergic to global state nowadays
<snusnu> instances ftw
<solnic> as in, hooking stuff onto class constantas
<solnic> constantas lol
<snusnu> heh
<mbj> solnic: spanish :D
<solnic> anyway, you know what I’m saying :)
<solnic> so yeah, mbj, round trip design :)
<mbj> solnic: dkubb does not refuse this, we AFAIK only finalized the public interface of already build types.
<solnic> i’m gonna leave it for virtus 2.0
<solnic> I will build it on top of current axiom types
<solnic> they give me what I need
<mbj> solnic, snusnu: I need your voice on this: https://github.com/mbj/mutant/tree/scoute-rename
<mbj> I renamed Mutant::Matcher to Mutant::Scout, and it does NOT make me so happy.
<snusnu> here's a thought: a domain modeled with instances only is more expressive .. in the real world there are no templates, it's all concrete .. templates are abstractions we make
<solnic> so basically attribute will have a type and the rest is..optional, it might have a name, a coercer etc
<solnic> depends on options
<solnic> mbj: what’s wrong with Mutant::Matcher?
<snusnu> real world things DO stuff, templates don't
<solnic> snusnu: I thought DNA is a template ;)
<snusnu> :D
<solnic> hey think about it ;)
<snusnu> arguably yes :)
<mbj> solnic: That "Matcher" itself does not fit within the naming domain of mutant.
<solnic> mbj: call it BadMotherFucker, should go in line with killers and stuff
<snusnu> and i'm not against classes obviously, but we mainly use them for instances don't we .. also, one could think of any living creature as an instance of its dna :p ..
<solnic> right
<snusnu> and afaict, i don't care about dna, i care about the creatures it produces :p
<solnic> on a related note, I almost did 10k run on Friday, how awesome is that? /cc elskwid
<mbj> solnic: cudos man!
<snusnu> did the app make you do it?
<snusnu> :p
<mbj> solnic: How that creature that made you run again was named?
<solnic> mbj: it was a huge leap from my previous top which was ~7km…and on Friday I did 9.67km so a huge difference
<mbj> solnic: /re BadMotherFucker, lets go with Mutant::Matcher
<solnic> result? my knee HURTS :/
<mbj> solnic: I stop running once I realize my knee starts to hurt.
<solnic> mbj: yeah I think distances like that might hurt you
<mbj> solnic: If it hurts later I cannot avoid it :D
<mbj> solnic: Your knee also "trains"
<solnic> I think I’m gonna hit the 10k and then chill out
<mbj> lulz
<mbj> solnic, snusnu: I'll stay with Matcher
<solnic> like just keep on running around 5-6 km, it’s a nice distance and takes only half an hour
<solnic> mbj: fwiw Matcher sounds completely fine
<snusnu> mbj: i still don't get why don't like Subject::Matcher when it does match subjects
<solnic> word
<mbj> snusnu: Because the rest of the Subject namespace defines subjects Subject::Method, Subject::Method::Instance, Subject::Constant (will be added later)
<mbj> snusnu: And a Subject::Matcher would imply the matcher *itself* is the subject.
<snusnu> not to me
<snusnu> i would never, without any docs, have the idea that a Mutant::Matcher would match subjects .. it wouldn't even take me a sec to know that when i read Mutant::Subject::Matcher
<mbj> snusnu: I'll leave it as is. I know it and this is enough, currently :D
<snusnu> :)
<mbj> So the infrastructure to allow mutation blacklists is set-up
<mbj> Hybrid mutation/subject blacklists
<mbj> I extracted the mutation only predicate system to Mutant::Predicate
<mbj> More and more of my code looks like an axiom clone :D
<mbj> I think we'll have axiom-logic in future for that stuff. I think axiom-types could be build on top of axiom-logic at some point.
<mbj> Maybe it will be "to slow", but I prefer having code reuse, and we can always generate "optimal" code via ast unparsing :D
<mbj> And modern JITed rubies will help is even more :D
<mbj> snusnu, solnic: I think mutant will soon start to do its own line-coverage analysis
<mbj> This will allow me to speed up mutation tests even more, because the test selection becomess really "narrow"
<mbj> And I expect my solution will be lots of faster than the one they do in simplecov, I have some ideas ready.
<solnic> sounds nice!
namelessjon_ has joined #rom-rb
kpwz_ has joined #rom-rb
namelessjon has quit [*.net *.split]
kpwz has quit [*.net *.split]
onewheelskyward has quit [*.net *.split]
Gibheer has quit [*.net *.split]
xargoon has quit [*.net *.split]
dbussink has quit [*.net *.split]
onewheelskyward has joined #rom-rb
xargoon has joined #rom-rb
dbussink has joined #rom-rb
Gibheer has joined #rom-rb