<nakilon>
havenwood need to split by arbitrary character
<havenwood>
nakilon: Have a minimal reproduction case or test cases?
<nakilon>
>> f = ->(a,b){ s,i,r=0,0,[]; until i==a.size do (r.push a[s...i] ; s=i+b.size) if i>=s && a[i,b.size]==b ; i+=1 end ; r+[a[s..-1]] } ; f["a aa a", "a"]
<nakilon>
>> f = ->(a,b){ s,i,r=0,0,[]; until i==a.size do (r.push a[s...i] ; s=i+b.size) if i>=s && a[i,b.size]==b ; i+=1 end ; r+[a[s..-1]] } ; f[" a a ", " "]
<nakilon>
the only "untrivial" thing is when separator is "aa" and there is "aaa" substring but I'm pretty sure what I've implemented is the same as you would find in some C++ STL lib
<nakilon>
just breaking the first match and +=sep.size
<nakilon>
or even in C libs
<leftylink>
very interesting
<leftylink>
if split(' ') is the only problem, perhaps split(/ /) can be used instead
<sweater2>
My brain gave up on this. Can someone explain basically everything around here, namely:
<sweater2>
What is `included`, or rather how does it work, what is `attr_reader`, what is this password=password @password password; super magic?
<sweater2>
It _looks_ like a function that takes a password, attaches it as a member to a new closure and returns either an instance of the parent class or nil
<sweater2>
So, kind of a very weird setter, but I'm fairly certain I'm fairly wrong. Halp.
gearnode has joined #ruby
<denny>
sweater2: included is part of the ActiveSupport::Concern stuff iirc - for setting up mixins. It's just syntactic sugar, you can do the same stuff without it but I forget how.
<denny>
sweater2: in this case ... that getter will be available in any class that includes this module
<denny>
attr_reader creates a getter method, which will return the value of the same-named instance variable
<leftylink>
ah too bad, I thought included was in Module, but it looks to me like it's a different included
<sweater2>
denny: thanks
<sweater2>
but what's `password` there then?
<sweater2>
is it a setter?
<sweater2>
how does it work.
<weaksauce>
attr_reader is shorthand for creating a default getter and password= is the setter
<denny>
then the password method is the setter for that same var
<weaksauce>
attr_accessor does a setter and getter for you
<sweater2>
weaksauce: is `password=` an identifier?
<denny>
they've used a method for the setter rather tahn using attr_accessor so that they could add the call to super
<sweater2>
or is it `password` -- the identifier, and `=` some modifier for it?
<weaksauce>
and attr_writer is the one that creates a default setter for you that is password=
<denny>
'password=' is the method name
<sweater2>
understood
<denny>
so in the code when you write 'password = "foobar"', that method is called
<weaksauce>
attr_writer :password is the same as def password=
<sweater2>
ah
<weaksauce>
but they don't use that because they want to do other things
<weaksauce>
when writing to the attribute
smurfke_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sweater2>
weaksauce: I only see that they return super if super exists?..
<weaksauce>
correct
<sweater2>
which I can't wrap my head around. (I'm coming from Elixir / Haskell, so I haven't seen OOP in a while, especially that kind)
<leftylink>
it's more important than returning it because it would call it
<sweater2>
Like why wouldn't they just return current object
<denny>
My personal take (coming from Perl, a much scorned language!) is that Ruby likes magic; if you're not familiar with the idioms then it can be a bit much sometimes.
<sweater2>
(sorry for extremely stupid questions)
<denny>
But once you're used to them it's obviously very neat and cool
<denny>
Also, fwiw, I would guess that Devise is a pretty hairy codebase, because it does some very complex integration stuff? That is a guess, but ... probably quite a hard bit of code to read through if you're not coming from a Ruby background in the first place.
<sweater2>
denny: what I dislike the most is that there is more often than not, no way to understand where something was defined or slapped onto something else. Conversely, reading a module definition doesn't guarantee that you have the complete picture.
<sweater2>
But these all are tradeoffs for convenience for people who know what they are doing (tm)
<sweater2>
and where too look.
<sweater2>
So I'm not too upset, taking it on the chin so far.
<denny>
Rails explicitly has the 'motto' or whatever of 'convention over configuration' - basically, do it the same way as everybody else and it'll run smoothly. Try to do it a bit differently and, well, steering off of the Rails doesn't generally end well :)
<sweater2>
denny: oh yes, it's OK, I am adding SSI to Mastodon, so there's no way around implementing Devise model + Warden strategy
<denny>
(Meanwhile Perl has "there's more than one way to do it" - culture clash much!)
<denny>
Cool. Good luck!
smurfke_ has joined #ruby
<weaksauce>
yeah i'd think devise is a bit hairy too
<weaksauce>
sweater2 there are some introspection methods too
<weaksauce>
but not entirely reliable iirc
denny is now known as denny-_-
<weaksauce>
i can't remember if it handles metaprogramming off the top of my head but source_location is one method you can use
<denny-_->
I've found just doing 'ls ClassIAmCurrentlyFighting' in a pry console is quite educational
<denny-_->
And often terrifying when you realise how much other stuff anything in Rails is attached to :D
<weaksauce>
hah
<denny-_->
also my mind was blown by an interview candidate a year or two ago doing 'cd instance_of_object' and then 'ls' and then poking around in its instance variables
<denny-_->
pry is lots of fun, either Perl doesn't have anything similar or I just didn't get introduced to it
denny-_- is now known as denny--
<weaksauce>
heh
<weaksauce>
activesupport concern is just two methods
<denny>
I haven't quite got my head around the difference between included { def self.foo ... } and class_methods { def foo ... } in a module and defining them in a class and inheriting them from another class. No doubt there are fairly clear rules (I think some things append methods and others prefix them), but so far I just hit it with a stick until it seems to work.
<weaksauce>
yeah i read the metaprogramming ruby book and the object hierarchy is odd and there is a lot of malleability and footguns
smurfke_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]