<dkubb>
obviously that inner code differs for each object
<dkubb>
when each is passed a block it's supposed to return self
<cored>
quite interesting
<cored>
also using to_ary I won't have to define the block as argument explicity
<cored>
in fact never mind, I just said a nonesense
<cored>
you are explicity passing the block to the internal state of the object
<dkubb>
in this specific case, yes, but it's not always that way
<cored>
which points me to the other question, in the end I'm returning a transformed data, I'm guessing that the reason to return self is to encapsulate the internal data structure that the object use
<dkubb>
the main thing is you want to yield the block with the object the caller would expect
<dkubb>
the rule of thumb I typically use is that I try to split up methods into two categories: query methods and command methods
<dkubb>
a query is allowed to return a meaningful result, but it is not allowed to change state. I can freely call it as many times as I want, safely, without modifying anything
<cored>
yes, I follow that advice from the partial work I'm doing with devtools
<dkubb>
it's almost always idempotent
<cored>
now I'm thinking that one of my collection Words in particular doesn't need to include Enumerable
<dkubb>
a command method is allowed to change state, but it cannot return a value that can be queried.. some people return nil from these methods, but I like to return self because it allows me to chain things
<cored>
oh, now I remember why I addded it that, it was just to use map on it without defining it
<cored>
yes
<cored>
that's what I'm trying to do
<cored>
probably I can simplify this code a little more following does guidelines and decoupling a little more
<cored>
this was an interview assignment, I tried it to solve the best way I could
<cored>
there are some methods that mutant add nil at the end or raise an exception
<cored>
from which I'm not testing and I want to add more tests for it the thing is that in particular the File part returns always nil
<dkubb>
yeah, if mutant adds nil, and the specs don't fail, it probably means you're not testing the return value
<dkubb>
the return value of every public method should be tested imho
<cored>
in fact the spec did not fail because I'm not testing for that
<dkubb>
cored: what is the purpose of the Words class?
<dkubb>
cored: a better word than purpose is "responsibility". every class/object should have one responsibility. it should generally aggregate different objects or add behaviour (or remove behaviour in some cases to provide a simpler interface)
<cored>
dkubb: is a collection for wrapping an array of strings
<cored>
but I'm feeling there's another type hidden in the code
<cored>
I was thinking in Word in particular to wrap the actual Strings inside my own type but that's also looks more like a data container without any type of particular behaviour at least I can't see it at the moment
<dkubb>
I personally wouldn't bother with the :in alias
<cored>
you would call .new directly ?
<dkubb>
yeah, probably
<cored>
I was thinking in some sort of DSL at first, it didn't end as I expected
<cored>
something like Sequence.in(word).not_included_in(Sequence)
<dkubb>
I try to limit custom constructors to very specific cases. if I saw SomeClass.in I might not be sure what it does without looking at the code, but if I see SomeClass.new it's very likely I know what it does without looking
<cored>
but in the end the way I'm representing the data structure assures me to have uniq values for the keys which is what I want
<cored>
good thought
<cored>
what do you think about my Collection[]
<cored>
way to construct collections, I copy that from Hash[]
<dkubb>
every line of code has to justify it's existence. if it doesn't have a strong reason for being there I would remove it
<dkubb>
I would probably also remove the [] constructor, at least for now
<dkubb>
those kinds of things are sugar and can be added back in later. I would focus on the basics at first, you might find you don't need sugar
<cored>
I see
mkristian__ has quit [Quit: bye]
<cored>
dkubb: but take into account that [] is very explicty what is doing
<cored>
parting from the fact that there are other objects in the language that do same thing
<cored>
in fact now that I see there's no such thing for instantiation