<snusnu>
dkubb: i realize that we want to mutate the expressions forming a conditional, that's a good thing. in this case tho, the method called does nothing but raise, hence there's no way to check how the code would behave if the call to that method is negated
<snusnu>
dkubb: also, i cant find any other way to write that method that is equally nice to read. and kills all mutations. inlining the raising into #processor(name) has the same problem, it also tries to negate the raise
<snusnu>
dkubb: i realize that i could do sth like: p = detect(name); return p if p; raise_unknown …. and mutant is happy, but imo it shouldn't perform that mutation in the first place (i.e. it should never try to negate a raise)
<snusnu>
dkubb: if i were to change my code to the above suggestion, mutant would effectively push me towards writing uglier code, something we don't desire at all
cored has quit [Ping timeout: 260 seconds]
<dkubb>
snusnu: I think you're right. I hadn't considered that case before
<dkubb>
snusnu: I think there may be another way to test everything that works
<dkubb>
snusnu: I can do something like: true or true -> not true or true (which we do now) and: true or true -> not(true or true)
<dkubb>
snusnu: that way if the second branch in the conditional is taken, then the negation will apply against the return value from that
<dkubb>
snusnu: worst case it's an equivalent mutation if the first branch is taken and it can be killed with the same test
<snusnu>
dkubb: yeah thx! the issue comment made a lot of sense! sums it up nicely .. i remembered reading about relation variables, and how they are basically what "gets around" the immutability, by being the thing an inserted/updated/deleted relation is assigned to iirc
<snusnu>
dkubb: re the mutation, i guess your suggestion would work too, my first thought was checking if the node to mutate is a raise, but your approach might be more general
<dkubb>
yeah
<dkubb>
the problem is the rhs can do anything it wants
<dkubb>
it could even "look" like a boolean method, eg: false or valid?
<dkubb>
and valid? could raise
<snusnu>
right
<dkubb>
so mutating it to false or !valid? won't help
<snusnu>
right, one would need to look deeper, which probably wouldn't work
cored has joined #rom-rb
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
<dkubb>
snusnu: I think I fixed that mutation issue you reported
<snusnu>
dkubb: i dunno, maybe i'm just not used to it .. but i tend to always qualify constants with the one they're defined in
<dkubb>
snusnu: I generally like minimal code and relying on scoping to resolve constants
<dkubb>
snusnu: in this case you're under the Chain namespace, so it doesn't seem confusing for you to assign EMPTY to the failure_chain variable
<dkubb>
snusnu: given the variable naming it almost seems redundant to do: failure_chain = Chain::Empty
<dkubb>
er failure_chain = Chain::EMPTY
<snusnu>
dkubb: maybe it's a naming issue .. EMPTY is very general .. maybe i should rename the const to EMPTY_CHAIN
<snusnu>
otoh Chain::EMPTY_CHAIN feels a bit weird too
<dkubb>
snusnu: i think the local variable gives enough information, but yeah, that did occur to me also
<dkubb>
snusnu: and the weirdness occured to me too, which is why I didn't mention it ;)
<dkubb>
snusnu: I like that mutant nudges us in a direction of minimal code. if something can be removed and a spec doesn't fail *and* it's impossible to make a failing spec, then I think that code should be removed
therabidbanana has joined #rom-rb
<dkubb>
snusnu: not just in this case, but in the general case. mutant is good at finding dead code and redundant code
<snusnu>
dkubb: yeah, i guess i agree … i will adjust my style, it's easier with good reasons ;)
<dkubb>
:)
<snusnu>
yeah
<snusnu>
dkubb: btw, re making code warning free … do you have any idea for the issue with private sections with readers vs. explicitly setting readers private?
<snusnu>
i have absolutely no idea why mutant would behave differently for those 2 cases
<dkubb>
snusnu: I don't know either. I'm guessing it's using ruby's introspection methods, and there's a bug in the code?
<dkubb>
snusnu: and yeah, I would generally use "attr_reader :name\nprivate :name" myself
<dkubb>
snusnu: have you created an issue on the mutant tracker?
<dkubb>
snusnu: once you do that I can look too
<snusnu>
dkubb: hmm i dunno, that's another style thing, i actually never liked that and preferred sections .. then again, the warning is yet another good reason to change style ;)
<snusnu>
dkubb: yeah, i will open an issue
<dkubb>
snusnu: I think private/protected sections are better for actual method declarations only. it's not always clear what someone's intentions are when they add an attr_reader inside those sections. sometimes I think they meant it to be public but lost sight of what the scope was
<dkubb>
snusnu: I prefer seeing attr_* declarations near the top of a class anyway
<snusnu>
dkubb: fair enough, i will change my style here too .. lemme doublecheck that case again, and open an issue if it's still a problem
<dkubb>
kk
solnic has joined #rom-rb
<snusnu>
dkubb: lol, seems like i messed up previously, i just ran mutant on Substation::Processor with explicit private readers, and it's all good :)
<dkubb>
snusnu: sweet
<dkubb>
snusnu: yeah, I was wondering what could possibly be the cause of that issue
cored has quit [Ping timeout: 264 seconds]
<snusnu>
dkubb: i must've forgot to move the private keyword down because there are other actual private methods in that module body
<solnic>
dkubb: your reply to snusnu re relation::variable is like a micro-book ;)
<dkubb>
solnic: haha
<snusnu>
dkubb: i guess i only made the readers private explicitly, thus leaving the supposed to be private methods, public
<dkubb>
solnic: sorry about that. I had to explain it for my own benefit too, because up until then it was all in my head
<snusnu>
i very much enjoyed reading that!
<solnic>
dkubb: it made me discover a feature in mailbox app called "show reset of this message" ;)
<solnic>
rest*
<solnic>
dkubb: I'm joking :) it was very informative :)
<dkubb>
heh
<solnic>
yeah it's very good to write down your own thoughts to sort of a double-verify them
<dkubb>
it might turn out to be wrong, but that's the best information I have at the moment
<solnic>
we'll see, it makes sense to me (fwiw)
<solnic>
btw should we be concerned about relying on proxy objects so much?
<solnic>
lots of method missing happening under the hood
zekefast has quit [Quit: Leaving.]
<snusnu>
dkubb: without thinking too much about it, it seems like the concept of a relation variable pretty much would be that "shim" you were talking about initially? "shouldn't" it be so that you can only ever write to relation variables, and not to the relations directly?
<snusnu>
dkubb: the relation variables would then expose the mutable aspect
<snusnu>
dkubb: which it seems to me, is their purpose anyway
<dkubb>
solnic: these are not really generic proxy objects, we know most of the methods they are going to delegate so we could define methods to perform delegation and only use method_missing as a backup; for things like mixed-in behaviour
<dkubb>
snusnu: yeah, that's exactly right
<dkubb>
snusnu: originally because the thought came so quickly I kind of dismissed it because I thought it might be a hack
<dkubb>
snusnu: now that I'm thinking about it more, I think it's the right choice. it should be the thing that you write to
<snusnu>
dkubb: yeah, it almost seems as if RA contains the concept of relation variables for exactly that reason
<dkubb>
snusnu: I'm still trying to think about where this breaks down, but I could make it so a base relation is a proxy, and it is this variable relation I talked about.. writes for memory adapters and rdbms adapters are propagated to it
<dkubb>
snusnu: yeah, exactly
<snusnu>
dkubb: by reason, i mean, that i think that RA "authors" were aware of the fact that any persistent datastore must contain a newly inserted tuple, when being read again
<snusnu>
dkubb: so the relation variable is sort of the persistent "table"
<dkubb>
snusnu: hmm. I need to check the examples. I can't recall what they show
<snusnu>
dkubb: you mean the definition of a relation variable in RA?
<dkubb>
snusnu: I'm using "The Third Manifesto" as kind of a textbook on everything
<dkubb>
snusnu: well, they have code examples for Tutorial D, which I kind of based axiom off with a ruby-fied interface
<snusnu>
yeah, i only skimmed through that like a year ago or so, but iirc, a relation variable serves exactly that purpose
<snusnu>
and, as we found out, it's a pretty foundational thing .. i mean, if something needs to be persistent, it *must* contain whatever changes you made to it, when you read it again
<mbj>
dkubb: hey, had a nice birthday event last day?
<dkubb>
mbj: yeah it was good. worked on oss all day and then went out for dinner with my family
<dkubb>
it's like a perfect day. now only if i could work on oss more ;)
<snusnu>
Database updates are performed by assigning the result of evaluating such expressions -- i.e., the results of queries -- to relvars, rather than being a series of ad-hoc table mutations. INSERT, UPDATE and DELETE operations on relvars are considered a convenient short-hand for assigning the result of a relational expression to a relvar.
<snusnu>
yeah, seems like relvars are there for exactly the problem we face
<snusnu>
obvioulsy, i copied that above statement from the website dkubb linked, i'm neither that smart, nor can i express myself that well in english :p
<dkubb>
hehe
<dkubb>
I think your english is awesome
<snusnu>
heh thx
<dkubb>
I forget that you, solnic and mbj are not native speakers all the time
mbj_ has joined #rom-rb
<snusnu>
oh wow thx again :)
mbj has quit [Ping timeout: 276 seconds]
<solnic>
dkubb: oh you do not *blush*
<dkubb>
solnic: no seriously. when I speak to you guys on irc I can't tell. it's only when we talk that I hear your accents and realize you don't always speak english all the time ;)
<snusnu>
it's all thx to the simpsons, futurama, of course southpark .. and oss :p
<snusnu>
well, at least for me, heh
<solnic>
dkubb: hah :)
<solnic>
yeah speaking IS HARD
<solnic>
I usually need a day or two to "unblock"
<solnic>
I suspect after few months living in US I'd be speaking with pure US accent :P
zekefast has joined #rom-rb
jessekempf has joined #rom-rb
mbj_ has quit [Ping timeout: 240 seconds]
zekefast has quit [Quit: Leaving.]
mbj has joined #rom-rb
<mbj>
re, unblocking and languages: it is significantly more easy with alcohol :D
<mbj>
I'm in a train so my connection is unstable again. Good moment to start working on mutant again :d
<dkubb>
ok yeah, that "nil::Bar" mutation is wrong. it should just mutate "Foo::Bar" to simply "Bar"
<dkubb>
"nil::Bar" works on MRI, but fails on jruby and rbx
<dkubb>
right-so I think
<mbj>
dkubb: You can access parent nodes type in mutant to guard for this mutation.
<dkubb>
ahh ok cool
<jessekempf>
mbj: by 'and' do you mean '&&'? '&' is the binary operator, '&&' is the boolean operator, and 'and' is the perl operator meaning 'after doing the first thing do the second thing'
<mbj>
jessekempf: and and && are both binary operators
<mbj>
jessekempf: binary in sense of they operate on left and right nodes.
<snusnu>
dkubb: i will write that support module providing {private, protected}_attr_* methods
<snusnu>
dkubb, mbj, solnic: any suggestions for a name?
<dkubb>
snusnu: I dunno. I'd probably start with AttributeHelpers until I could think of a good name
<snusnu>
dkubb: fair enough
<dkubb>
snusnu: it probably goes without saying, but I would make it so you have to do: extend AttributeHelpers. I wouldn't automatically mix it into Module or anything.
<snusnu>
dkubb: of course, yeah
<jessekempf>
mbj: well, true, but (x = y and z) != (x = y && z). (x = y and z) == ((x = y) && z). In general one doesn't want to use the 'and' operator in place of the '&&' operator in a boolean context.
<mbj>
jessekempf: our policy is to use or/and for control flow and &&, || for operations that result in true/false
<mbj>
so if you implement a predicate you'd use &&/|| but if you do control flow you use and/or
solnic has quit [Quit: Leaving...]
<mbj>
jessekempf: pls note I'm on a train and loose connection often. I'll try to rejoin.
<jessekempf>
mbj: no worries
dkubb-ircloud has joined #rom-rb
<dkubb>
mbj: I can't wait to start on the regexp mutations. I think there's a whole world of possible mutations in that
<dkubb>
mbj: afaik, no mutation testing tool has gone into that before. obviously I think the generic mutators should be updated first, but regexp mutation would open up lots and lots of mutations
<snusnu>
dkubb: i will mutation test and gemify it later today
<snusnu>
dkubb: gem name attr_helpers ? (free)
<dkubb>
snusnu: it sounds kind of generic.. I dunno. are there other kinds of attr helpers you can think of? maybe the same ones, but for singleton methods?
<dkubb>
snusnu: actually, I can think of one bug in this
<dkubb>
snusnu: in your private_attr_accessor you're only calling private on the reader method it creates, not the writer method
<snusnu>
dkubb: true, thx for spotting!
<dkubb>
snusnu: you could make it so private_attr_accessor did private_attr_reader and private_attr_writer
<snusnu>
dkubb: yeah
<dkubb>
it's kind of doing the work of attr_accessor
<dkubb>
but the alternative is to do even more
jessekempf has quit [Quit: Leaving.]
<snusnu>
dkubb: one possibly confusing side effect of doing that, would be documentation, altho i guess it's fine .. it wouldn't be *wrong* if you were to write docs for an rw attribute
<dkubb>
snusnu: yeah, I see nothing wrong with that
solnic has quit [Read error: Connection reset by peer]
<snusnu>
dkubb: what did you mean above, when you asked if there are other kinds of attr_helpers i can think of? for singleton methods? wouldn't it work to just extend AttributeHelpers like class << self; extend AttributeHelpers; end
solnic has joined #rom-rb
<dkubb>
snusnu: yeah, I think I would ignore that statement. I rarely make class level attributes anyway
<snusnu>
dkubb: yeah, me neither
<dkubb>
snusnu: and yeah, I would do it the way you suggested. i'd only think about making it simpler if that code was repeated a bunch of times in various places
<dkubb>
snusnu: we *know* we'll be repeating "attr_reader :name; private :name" all over the place so it makes sense to extract it out
<snusnu>
dkubb: yup i totally agree .. and imo it's a pity ruby doesn't have those builtin
<snusnu>
dkubb: tried adding a method summary, yardstick complains, tried adding an @api tag, yardstick complains
therabidbanana has joined #rom-rb
zekefast has joined #rom-rb
<dkubb>
snusnu: I think it's because yardstick doesn't know about this new syntax. do you want to open an issue in it's tracker to begin supporting these?
<snusnu>
dkubb: yup will do
<dkubb>
snusnu: for now i would adjust the yardstick threshold to match whatever your current threshold is
<snusnu>
dkubb: i was about to ask that, and yeah, i will do just that