<dkubb>
ok, I've added https://github.com/dkubb/axiom-memory-adapter .. it's just a basic skeleton atm. I've stubbed out and documented the CRUD methods in the adapter, and now I have to implement them which I will be working on over the next week or so
splattael has joined #rom-rb
jdsiegel has quit [Ping timeout: 240 seconds]
solnic has joined #rom-rb
travis-ci has joined #rom-rb
<travis-ci>
[travis-ci] rom-rb/devtools#6 (master - e9a19f0 : Dan Kubb): The build has errored.
<dkubb>
(in fact nothing to see really, aside from YARD docs on the methods)
<solnic>
dkubb: wow how is it gonna work if it's immutable?
<solnic>
yeah it looks the way I was imagining it more or less
<dkubb>
solnic: I'm not actually sure yet ;)
<solnic>
haha
<dkubb>
solnic: well, that's not entirely true. I have a couple of ideas but I wanna test them first
<solnic>
I was thinking about some in-memory store that would be passed to the adapter
<dkubb>
what will probably happen is it will modify something in memory inside the adapter, so that next time the adapter#read is called they'll get the new data
<dkubb>
sort of like if there was a real database undeer the hood
<solnic>
yes
<dkubb>
I don't want to do anything crazy like modify tuples in an Array that a relation holds a reference to
<solnic>
well we could have an in-memory store that's immutable
<dkubb>
that could produce some crazy results
<solnic>
but that'd be weird imho
<dkubb>
I'll probably isolate it in side the adapter
<dkubb>
it'll likely be something simple like a Hash mapping the base relation to an Array of Hashes
<solnic>
rite
<dkubb>
*mapping the name of a base relation
<solnic>
I started with a hash indexed using keys
<solnic>
and tuples as values
<dkubb>
I'll likely do a but of locking when modifying the hash to make sure it's thread safe
<dkubb>
yeah, I may use tuples under the hood
<dkubb>
it could also simply be a Hash of materialized relations
<dkubb>
but then there's the issue of modification
<dkubb>
actually that's not too hard
<solnic>
yeah initially I thought about just using relations
<solnic>
actually no
<solnic>
it was my initial assumption
<solnic>
that it's gonna just use those
<dkubb>
you can do stuff like: registry[:users] |= new_tuples
<solnic>
I believe snusnu thought the same that's why he expected it to just work™
<dkubb>
that's for insertion
<solnic>
it's not that trivial though :)
<dkubb>
deletion is registry[:users] =- tuples
<dkubb>
it may actually be :P
<dkubb>
well, with a mutex
<solnic>
well
<solnic>
trivial as in it would work already inside rom
<solnic>
that's what I meant by trivial
<dkubb>
oh, well, hthere's the unwinding of the relation.. that's a bit harder
<solnic>
snusnu didn't realize we need a gateway
<solnic>
he assumed returning the base relation back to rom is all we need
<dkubb>
you have to figure out all the base relations from an existing relation
<solnic>
yes that's tricky
<solnic>
that's where I got stuck
<dkubb>
maybe, I have some ideas
<dkubb>
I should be able to invert most relations so I can get all the base relations along with the operations applied to them that need to be applied inside the registry
<dkubb>
some can't be, like an insertion into a union, but most should be writable
<dkubb>
all that will be done inside the adapter. I'll likely push this up to a base adapter once it's solid
<dkubb>
from the pov of the adapter caller, it will be a black block.. you insert some tuples, then read and the new tuples should be returned. what is happening inside the adapter to "persist" it shouldn't be exposed
<solnic>
I guess we can start simple and add support for more complex cases later
<solnic>
it's not like you'll be blocked later if you don't start with complex stuff initially rite?
<dkubb>
yeah, I'll start with the simplest possible thing, inserting into a base relation, and then work up from there
<solnic>
rite
<dkubb>
nah, I figure base relations first, then restrictions, and then move through the operations one at a time
<solnic>
sweet :)
<dkubb>
I might even try to do all the ops for base relations first so at least there's *something* you can build on
<solnic>
mbj: can you remind me which laptop did you get?
solnic_ has joined #rom-rb
solnic has quit [Read error: Connection reset by peer]
solnic_ has quit [Client Quit]
kapowaz has joined #rom-rb
jdsiegel has joined #rom-rb
<mbj>
splattael: lenovo W530
<mbj>
splattael: sorry, was for solnic
solnic has joined #rom-rb
<mbj>
solnic: Lenovo W530
<mbj>
solnic: If you like 15" notebooks you'll like this device.
<mbj>
solnic: I put in 4x8GB of ram, and a 250GB ssd
<mbj>
solnic: Ordered a stock config and changed the parts for myself, very easy and does not void warranty.
<solnic>
mbj: I may try to work on linux again later this year
<solnic>
I think I'd get xps 13
<mbj>
solnic: The 4 ram slots are the killer feature for me, dont like less poerful machines :D
<solnic>
mbj: do you actually make use of so much ram?
<solnic>
I have 8 gigs and it's mostly free
<mbj>
solnic: jo I do
<mbj>
solnic: Play around a lot, I'm not only using ruby
<mbj>
solnic: Also i was stuck with that underpowered machine for some time, this had to change ;)
<solnic>
mbj: re rom-session question, I'm actually having trouble imagining it to be decoupled from the rest of ROM, it doesn't make sense IMHO to make it a stand-alone thing given we need a close integration with axiom/rom
<solnic>
remember that I want the same interface exposed by rom's relation and session
<solnic>
otherwise it will be confusing to use and just crappy
<solnic>
I see session as rom's relation extension, nothing else
<solnic>
it is basically a db interface with state tracking, IM and UoW
<solnic>
it has to be built on top of rom's relation, I can't imagine it being done in a different way
<solnic>
with injectible mapper we actually only solve 1 problem - loading the same object twice will be intercepted, which is nice because that's the promise of using IM
<solnic>
so this feature alone is great
<solnic>
but eventually we need to intercept db calls, that's gonna be tricky and require some axiom magic too
<solnic>
also, because rom-session shuold have the same interface as rom-relation, we shuold make sure that the effort to achieve this is very small
<solnic>
in fact, I started considering using a run-time extend for session's relations
<kapowaz>
solnic: hey there.
<kapowaz>
so, I'm off work sick. Got a nasty cough and chest infection which meant I couldn't sleep. Was awake since 5am.
<kapowaz>
so I decided to try and do something productive. I've sketched on an idea, if you're interested in seeing.
<mbj>
solnic: I think rom-session could be renamed to rom-persistance-state-machine, and a real rom-sesison should be made.
cored has joined #rom-rb
cored has joined #rom-rb
<cored>
morning all
postmodern has quit [Quit: Leaving]
<solnic>
cored: morning
<solnic>
mbj: well, that could be an option
<solnic>
however rom-persistence-state-machine is a bit too long
<mbj>
solnic: rom-pstate
<solnic>
rom-tracker?
<mbj>
solnic: I describe it as persistance state machine
<mbj>
solnic: jo!
<mbj>
solnic: rom-tracker!
<mbj>
solnic: that it.
<solnic>
:)
<mbj>
*thats
<mbj>
Because sometomes a mapper is overhead you dont need.
<mbj>
Also I use it for handwritten mappers a lot, so I'd like to follow this path.
<solnic>
mbj: it only needs to inject its specialized mapper to work rite?
<solnic>
so basically we could inject a 1:1 mapper that just adds tracking
<solnic>
oh wait, what about IM?
<mbj>
solnic: that tracker has an im
<mbj>
solnic: think about persitance state tracker
<mbj>
it knows if a specific object is already in memory
<mbj>
It only needs object compatible with loader and dumper interface to do its job.
<solnic>
mbj: what is rom-session then?
<mbj>
solnic: can move into rom-mapper
<mbj>
solnic: or can hold the uow?
<mbj>
solnic: Or it is the mapper with session integration!
<mbj>
rom-mapper | pure mapper w/o state tracking
<mbj>
rom-session | augments rom-mapper with state tracking ?
<solnic>
rom-session could integrate mapping with state tracking
<mbj>
jo
<solnic>
hmm
<solnic>
it still must extend functionality of the injected mapper
<solnic>
so it can do its magic in load/dump
<solnic>
ah ok
<solnic>
we can inject new mapper easily since whole dump/load magic happens inside loader/dumper anyway
<mbj>
jo
<mbj>
I thin rom-tracker will have a really sharp interface, it is the "heard".
<mbj>
Most likely features of rom-trackers can be used by a UoW also
<solnic>
mbj: actually I'm missing something here
<solnic>
what would rom-tracker do exactly?
<solnic>
tracking state is strictly coupled with db ops that we're doing
<solnic>
I don't think I want to introduce this tracker now
<solnic>
first I want a working session with basic UoW
<mbj>
solnic: rom tracker externally associates a persistance state with a tracked domain object.
<solnic>
then we'll see what makes sense to extract
<mbj>
It tracks the persistance state of domain object
<solnic>
that's too general
<solnic>
I need details
<solnic>
what's the purpose of having it as a separate gem?
<mbj>
It is also able to detect if a domain object is dirty
<mbj>
solnic: So I can use it without an other rom-* gem.
<solnic>
how would you use it?
<mbj>
I handwrote lots of mappers in the last year using dm-session (rom-session) for state tracking.
<mbj>
Non generic mappers!
<solnic>
wdym?
<mbj>
Use case specific mappers. And repostory objects.
<solnic>
I see
<mbj>
These repository objects always had a dm-session instance internally to keep track of peristance state.
<solnic>
yeah I want to support whatever mapper you like to have
<solnic>
just expose loader/dumper stuff and you're done
<mbj>
Yeah, that is rom-tracker
<mbj>
It tracks domain objects persitance state and knows when to invoke a load and when not to do so.
<mbj>
I optimized rom-tracker to not do any useless dumping/loading
<solnic>
wait no, that's confusing things
<solnic>
tracking state is one thing, loading stuff from IM is another
<mbj>
You can give rom-tracker a dump and say: Give me the domain object for this
<mbj>
(You give it a loader!)
<mbj>
Rom tracker will check the loader for the identtiy, and if not calls #object on the loader.
<mbj>
*will check its im if it nows identity from loader
<mbj>
s/nows/knows/
<mbj>
omg so much backtracking
<mbj>
Let me redo:
<mbj>
Rom tracker will check its IM to see if the object corresponding to the #identity the Loader returns was loaded already
<mbj>
If it was loaded it returns the already loaded (tracked) object
<solnic>
that's pretty much what session does
<solnic>
that's session with IM
<mbj>
Session also integrates with mapper
<solnic>
not sure if splitting this into smaller pieces makes sense
<mbj>
Again I want to be able to use a pure session/tracker without any other rom-* gem.
<mbj>
And it makes sense to have such a small interface.
<solnic>
you can't use session without rom-relation
<mbj>
That is the reason to have rom-tracker
<solnic>
session is built on top of rom-relation
<mbj>
rom-session will use rom-tracker internally.
<mbj>
But I can cherry-pick rom-tracker for the stack
<solnic>
well, ok
<mbj>
To not have to throw away that perfectly working and mutation covered domain specific mapper and repo objects.
<solnic>
but as I said, first I'll make rom-session to WORK
<mbj>
I'm free with resurecting dm-session
<solnic>
then we'll see how to approach extraction
<solnic>
wdym?
<mbj>
If we see that separate rom-tracker does not make sense
<mbj>
But I expect it makes sense to we dont couple that internal stuff so hard.
<solnic>
well, it's gonna be very lously couple, mostly relying on simple loader/dumper interface
<solnic>
s/couple/coupled/
<solnic>
the only thing that worries me still is db interface, I want it to match rom relation's interface
<solnic>
session.read(User, :email => 'dasfas') is NOT how I'd imagine that
<mbj>
solnic: yeah
<solnic>
I see session as an extended rom relation
<mbj>
solnic: Me neighter!
<mbj>
I just made it work :D
<mbj>
(with that kind of interface from above)
<solnic>
you did? :)
<solnic>
oh I see
<solnic>
yeah
<solnic>
well ok, I'm gonna try to make it work (again) with rom-relation now
<mbj>
That is a more generic one that I wrote.
<solnic>
and then we can see how we could extract its tracker/IM part into something that doesn't depend on rom-relation
<mbj>
I expect we can remove some of the interface in rom-tracker soon.
<solnic>
oh and btw, when I say MAPPER I mean something that you called in your spike TRANSFORMER
<mbj>
I'll fork rom-session now, to make sure you dont break interfaces I use.
<mbj>
Yeah
<solnic>
just wanted to make sure we're on the same page with this
<mbj>
We have two things that could be named mapper!
<solnic>
no really
<solnic>
not
<mbj>
That mapper that transforms from domain to tuple
<mbj>
And that one that maps domain to db.
<solnic>
well, that's mapepr
<solnic>
mapper
<mbj>
solnic: BTW my spike is pullshit
<mbj>
s/pull/bull
<solnic>
it uses loaded/dumper internally
<solnic>
loader* geez
<solnic>
typo day
<solnic>
:)
<mbj>
I had a better spike, but lost it without pusing.
<solnic>
that's OK
<mbj>
*pushing
<mbj>
OMG.
<solnic>
I got the concept and refactored rom-mapper
<mbj>
yeah typo spike
<mbj>
nice
<solnic>
so it's inline with the required interface now
<mbj>
You piked up my concept? Really nice!
<solnic>
you didn't see it?
<mbj>
I'm not following rom-#{relation,mapper} because I'm to busy.
<solnic>
I'm pretty sure we talked about this in commit comments ;)L
<solnic>
:)
<mbj>
You did not saw any nitpicking :D
<mbj>
Nope, just check the logs, the only thing I was commenting about was sql
<solnic>
remember discussiong loader/dumper? how to call methods etc?
<solnic>
that was my rom-mapper refactor :)
<solnic>
anyhow
<mbj>
ah, okay
<solnic>
I'm gonna make rom-session to work with it now
<solnic>
it's kinda hard to start though with all the code being there already
<solnic>
but I'll try
<mbj>
But I tried hard not to read that part of rom-* in GH
<mbj>
It would be to distracting from commercial stuff
<solnic>
gotcha
<Gibheer>
solnic: how fast do you need a new laptop? As intel released the new processors, the new laptop models are released too in the next two to three months
<solnic>
Gibheer: I don't need it at all
<solnic>
Gibheer: I just consider switching to back linux
<solnic>
which may or may not happen
<Gibheer>
ah
<solnic>
if it happens it'll be probably later this year
<Gibheer>
why not use the macbook for that?
<solnic>
or even next year
<solnic>
Gibheer: it doesn't work so well
<Gibheer>
really? that is unexpected. Thought support would be fine
<Gibheer>
I'm looking for a new laptop for nearly a year now :(
<Gibheer>
there is just too much crap out there
<solnic>
mbj: I fail to wrap my head around rom-session with its current state
<solnic>
it seems like it's missing quite a lot of stuff
<solnic>
for instance uow :D
lorenzoo has joined #rom-rb
<solnic>
mbj: I think I see the tracker thing
<solnic>
it's basically what Session now is
<solnic>
we still need rom relation extension with injected session mapper
<mbj>
solnic: It should not be a UOW
<mbj>
it is a persistance state engine. Nothing more :D
<mbj>
I never tried to write an UoW!
<mbj>
I never tried to write the real rom-session.
<mbj>
It is just a pice of reestanding code that allows to form the heard of a persistance system.
<mbj>
(The state tracking heard).
<mbj>
call it rom-session-core :D
<solnic>
mbj: you mean "heart" right?
<solnic>
mbj: re uow, it should be part of session
<solnic>
session puts db commands in a queue managed by UoW
<solnic>
then when session flushes it uses UoW to execute the pending commands in correct order and finalize various things
<mbj>
solnic: cat lib/rom-session/lib/**/*.rb is the possible core of a session
<mbj>
nothing more or less :D
<mbj>
I know it is not a full session, and I wasted so much time in discussion it is not a full session!
<solnic>
yeah I keep getting back to it
<mbj>
hehe, yeah
<solnic>
I need to finally make it work
<solnic>
so we can move on
<mbj>
solnic: Just rm -r it
<mbj>
and write your own :D we wasted so much time discussing it :D
<solnic>
yeah, I think I want to start from scratch and import tracker once I have the relation extension + specialized mapper ready
<mbj>
solnic: do whatever is needed we dont discuss this an additional 12 times, no I'm not upset!
<solnic>
lol
<solnic>
sure
<mbj>
Once you did your own implementation you'll realize what part the present code already solves
<mbj>
And most likely you'll include it again.
<solnic>
I know which part is solves
<mbj>
I optimized it to the limits already.
<solnic>
at the same time there are some things that are not inline with the aproach we're talking
<solnic>
so it's hard for me to filter that out
<mbj>
Yeah, some of the interface is very repository like
<solnic>
s/talking/taking/
<mbj>
solnic: So just nuke it.
<mbj>
solnic: I'll read the stuff we need.
<mbj>
I get tired by the discussion, thb.
<mbj>
*tbh
<mbj>
mom, let me make a working ford!
<mbj>
s/ford/fork/
<mbj>
wohoo rom-session was forked to mbj/dm-session
<mbj>
found a bug in github...
<mbj>
solnic: done you can nuke!
<solnic>
mbj: no worries
<solnic>
I pushed a pre-refactor branch
<solnic>
for reference
<mbj>
Lets follow the rule: I could not explain what that code is useful for, so we nuke it :D
<mbj>
Apart from the fact I could extract it from various handwritten repositories.
<solnic>
no worries, this code will be re-added
<solnic>
I'll probably name it Tracker inside the namespace
<mbj>
jo
<mbj>
Ideally we once have a cherry-pickable gem
<mbj>
solnic: I'm not upset, just tired :D
<solnic>
because it was a tracker with some persistence mechanisms (it was calling various persistence methods on mapper)
<solnic>
yeah I'm tired of discussing session too
<solnic>
it's such a complex concept that I just need to start working on it to get it fully
<mbj>
solnic: the thing is, it works already :D
<mbj>
And really well!
<mbj>
We need to integrate it
<solnic>
I know
<mbj>
but not via pulling additional dependencies inside the tracker
<solnic>
I don't want to loose it
<mbj>
IMHO via pulling the tracker inside the thing it should be integrated with
<mbj>
the tracker wasnt a session
<solnic>
no it wasn't
<mbj>
so now we have a rom-session withaout a tracker
<mbj>
so we can pull the tracker inside the session
<mbj>
and have rom-tracker gem
<mbj>
done.
<mbj>
dunno why we iterated so often, we where in sync from the begining ;)
<solnic>
dkubb: a guy from my team suggested that, I can ask for more details :)
<dkubb>
we can use nice typography in the text, etc. I was thinking the logo could be blocky leters
<kapowaz>
well I can certainly have a go at throwing something together
<dkubb>
sorry I'm I'm shitty at explaining this. I'm not usually on the visual side of things
<kapowaz>
I did make a retro logo for something a while back, I'll find it, see if it's remotely in the sort of style you're talking about
<dkubb>
when I thought of the logo I was thinking about the way the old-school IBM logo looked: http://www.google.ca/imgres?imgurl=http://upload.wikimedia.org/wikipedia/commons/5/51/IBM_logo.svg&imgrefurl=http://commons.wikimedia.org/wiki/File:IBM_logo.svg&h=400&w=1000&sz=5&tbnid=4hkHdcpLHjAwFM:&tbnh=48&tbnw=119&zoom=1&usg=__eLeC3kxkHJG-xKvmO9vj01TmUe8=&docid=eHAMqj5HuQfymM&sa=X&ei=KyDDUdn3MYiTiQKrlYDICg&ved=0CC4Q9QEwAA&dur=353
<dkubb>
yeah my first thought was a green blocky "ROM"
<solnic>
I think I'm digging that idea
<cored>
dkubb: hi
<dkubb>
either blocks, or "dotty" like: http://www.google.ca/imgres?imgurl=http://www.dedoimedo.com/images/life/movie-hacking-leet-terminal.png&imgrefurl=http://www.dedoimedo.com/life/movie-hacking.html&h=631&w=649&sz=290&tbnid=JSk6x-9J5ysWjM:&tbnh=90&tbnw=93&zoom=1&usg=__7x91BdGSDNrlFCfa4f-wNv0DrRI=&docid=QhqomzZCjVRQlM&sa=X&ei=pSDDUdWaEYH9igKG2ICwCw&ved=0CEoQ9QEwBA&dur=410#imgdii=JSk6x-9J5ysWjM%3A%3Btj-hWctCdfSo0M%3BJSk6x-9J5ysWjM%3A
<dkubb>
(not inverted text like this though)
<solnic>
that'd be cool too
<dkubb>
cored: hey, how's it going? sorry for not providing such good direction yesterday. I was in between work
<dkubb>
cored: hopefully you were able to trace through how things worked and how axiom would need to change to use axiom-types
<cored>
dkubb: in fact, not :-P
<cored>
dkubb: I spend like 4 hours just reading the code trying to figure out how to infer a type using Axiom::Types
<cored>
it's weird to me
<cored>
the specs says Axiom::Types.infer but it doesn't work when I call that method
<dkubb>
cored: it's ok. I probably need to give some better direction or spike something really basic out
<cored>
well, you can start now with the direction if you have time :-) I'm planning on help as most as I can
<dkubb>
cored: it's a bit weird. basically what it does is takes a class, iterates through all the type subclasses and the first that matches it will cache it and reuse it in the future
<dkubb>
cored: it's not about inferring a type based on an actual object instance, but rather that object's class
<dkubb>
cored: so you'd use it like: string = "Hello World"; Axiom::Types.infer(string.class)
<dkubb>
cored: obviously we know string.class == String, but you get the idea
<dkubb>
cored: for every new class it will do this somewhat expensive lookup, but it'll cache it and reuse the lookup next time
<dkubb>
cored: in a long running application I would expect that after a few cycles the cache would be primed and the lookup would be fast. although really, inference is probably not going to be used a ton
<cored>
I see
<cored>
as I said I started with Boolean yesterday
<cored>
there is an expectation on the specs asserting on a value TrueClass which I can't find in Axiom::Types
<cored>
don't know if you saw my last gist, regarding this changes
<dkubb>
cored: can you show me which specs you mean?
<kapowaz>
so that I could get her to brainstorm ideas along with me
<kapowaz>
her idea was the one that set me off on the path of the ‘links’ one — the idea of nodes connected
<kapowaz>
she described it a bit like a tube map
<kapowaz>
in the end what I've gotten is more like meccano (if you remember that)
<dkubb>
cored: so here's what I'm thinking: the sole purpose of the .primitive class method is that axiom uses that to match against an object for type inference
<kapowaz>
(hence the hexagons — they're supposed to be the heads of bolts)
<dkubb>
cored: if we're moving towards axiom-types, then .primitive can probably go away, but we'd need a method that we can supply a class object to and have it return the correct Axiom::Attribute subclass
<dkubb>
cored: I wouldn't get hung up on making .primitive work. you can probably remove that method and the corresponding spec. the main thing is that the type inference still works
<cored>
but as I'm not using inherantance don't know how Axiom will infer the type without that method
<kapowaz>
since I'm in here and people are awake, I have a DM question — is there a validation for numeric types, to enforce range? I know there's validates_length_of for strings, but is there something similar to ensure that the value is within a range?
<dkubb>
cored: I think the main reason for that method is so an instance can be validated by the type. axiom-types has that built in: type.include?(object)
<kapowaz>
yeah, solnic said you thought that
<mbj>
heh
<kapowaz>
the saturation can be turned down easily enough
<solnic>
I like those colors
<dkubb>
cored: did you see my explanation yesterday of how to think about a type?
<solnic>
alternatively we could reduce the number of colors (if possible)
<mbj>
I like bicromatic logos.
<solnic>
and see how that looks like
<cored>
dkubb: I did, but I think I did not understand it as I thought I did
<mbj>
kapowaz: But I really like the shape and the symbolics!
<kapowaz>
cool :)
<cored>
after you told me to think on replacing whatever Axiom is doing to know what thing is what
<cored>
I tried to just let the methods that it's currently using and switch it
<dkubb>
cored: ok so imagine there's this nearly infinite set that includes all objects. every possible object that can exist. when you have a type like Axiom::Types::String, you're slicing out a smaller set of that huge set
<kapowaz>
I think you should all take a moment to thank me for not creating anything Ferengi-themed :)
<dkubb>
cored: I have a method like Axiom::Types::String.include?(object) which will tell you if the object is within that set or not
<kapowaz>
I considered it.
<kapowaz>
I remember when I was still at Videojuicer I helped Andre create a proof-of-concept app for something. I can't remember what the LS stood for, but it was the LSPOC. Might have been livestreaming.
<dkubb>
cored: you can define more types that are specializations of Axiom::Types::String.. like say a string that is between 1 and 100 chars long.. then ask it: my_smaller_string_type.include?(object)
<dkubb>
solnic: you could think of the colors as each component in ROM
<solnic>
yeah
<solnic>
me likey
<solnic>
mbj no likey
<cored>
dkubb: that's why you said that I should just remove .primitive
<cored>
dkubb: and try to check in there without that
<mbj>
solnic: ?
<kapowaz>
dkubb: I did give thought to that. There are 5 struts, but how many components does ROM have?
<mbj>
kapowaz: It grows :D
<kapowaz>
heh
<kapowaz>
the thing is, that logo could be modified ;)
<solnic>
kapowaz: full stack will have more than 5
<mbj>
kapowaz: We tend to create a new component once we see a pattern that could be deduped.
<kapowaz>
the three long struts can be split in half
<kapowaz>
so you could have 8 struts
<solnic>
but looking at it from a highlevel perspective
<mbj>
Soon we'll end up in logo driven design :D
<solnic>
axiom / mapper / session
<solnic>
three
<mbj>
"We cannot ad a new gem! Why? There isnt a logo shape anymore"
<solnic>
hehe
<dkubb>
cored: yeah, you can refactor the type checking/inference stuff to work in a way more like axiom-types.. still pushing the object into a type to ask it if it can handle it, rather than doing what we do now.. which is asking the type for all of it's properties and values, and then performing the logic elsewhere
<cored>
solnic: that's the one I have no problem at all, I'm not using Ubuntu though
<solnic>
cored: yes I'd buy that one if I decided to go back to linux
<cored>
solnic: great choice
<solnic>
its specs are fantastic
<dkubb>
cored: I usually spec methods with public visibility, although I am considering changing it to only spec methods with documented public interfaces
<solnic>
and it looks really lovely
<solnic>
which I cannot say about lenovo :P
<solnic>
dkubb: yes please...!
<cored>
dkubb: yes, it was kinda confusing for me, I checked the spec and then notice in the source code that the method doesn't exist but inside Axiom
<solnic>
I found spec-file-per-method to be a huge overhead making code harder to maintain
<solnic>
there's some value in it but the overhead it adds to the dev cycles makes it not worth the effort
<cored>
dkubb: I think that's the proper way to go, private methods normally are tested indirectly so why bother
<solnic>
=>imho<=
<dkubb>
solnic: mutant will probably need to parse YARD docs to determine what is part of the public interface
<solnic>
yes that's the trick
<solnic>
that's why I've been whining to mbj about improving mutant :D
<cored>
dkubb: but, back to our present time :-D
<cored>
dkubb: Axiom::Types::String.include?(object) of course works but that just say 'true or false'
<cored>
dkubb: after removing primitive there's a method named .infer_type is also private btw in Axiom::Attribute which I remove the primitive call but now I need a way to infer that type based on the object it's gets as a parameter
<mbj>
dkubb: Talking about the kill expressions, mostly.
lorenzoo has quit [Remote host closed the connection]
<dkubb>
cored: if you used Axiom::Types.infer_type to get the type class, then you could iterate over all the Axiom::Attribute subclasses to find the one with that type (assuming it was a class method)
<dkubb>
cored: the first iteration doesn't have to be pretty or super efficient. the main thing is to get axiom-types as the underpinnings of type inference and constraint checking. there's tons of room for refactoring and simplification
<cored>
parting from the specs and then reading the code which leads me to another topic with you; I don't think testing private methods return any benefits, so maybe mutant can say that if the user is testing private methods or not, but that can be on another discussion
<cored>
mbj: yes
<cored>
mbj: that method is actually public, but I'm getting a NoMethod error calling it, when I issue pry to check the method is not there, neither Axiom::Types::Type.infer is there
<mbj>
cored: I now we have two questions?
<cored>
?
<mbj>
cored: Ahh, you are not asking how to implement/port type inference
<mbj>
you ask about how to deal with private methods, and mutation testing?
<cored>
hehe
<cored>
sorry the last part was just an off topic
<mbj>
You said "another topic", so I thought you are about to split the discussion
<cored>
we can talk about that later
<mbj>
So what is the question?
<cored>
the question is that I want to use axiom-types inside axiom, take out all the uneeded code because axiom-types at the moment can infer types
<cored>
correct?
<mbj>
cored: Lets say it this way, I'd remove all stuff within Axiom::Attribute that deals with type
<mbj>
Than require axiom-types and make specs pass again.
<cored>
so, the primitive method is the one doing the inference at the moment, so if I remove that then it should be possible to make a call to axiom-types and infer the type, right?
<mbj>
While delegating all "type" stuff to that lib.
<cored>
wait a sec
<cored>
if I remove all that stuffs
<cored>
I know that Axiom::Types use it
<cored>
well, I want to do it step by step just because I want to know how this works, and of course without making a bigger mess
<cored>
I was trying to delegate I started using Axiom::Types from within the same Attribute classes inside Axiom
<cored>
but couldn't
<mbj>
Where was the problem?
<cored>
Boolean.primtive had this ::TrueClass
<cored>
I was trying just to return Axiom::Types::Attribute::TrueClass
<cored>
at first
<cored>
did not exist, then Axiom::Types.infer(true) same thing
<cored>
in this case NoMethodError for .infer
<cored>
mbj: I will do something I will remove attribute/boolean.rb
<cored>
mbj: and when the specs start to failed I will change the type from Axiom::Attribute::Boolean to Axiom::Types::Attribute::Boolean
<cored>
that was your suggestion, right ?
<mbj>
cored: I dont really get what your problem is, sorry.
<mbj>
But as a note, Boolean is most likely a problematic attribte
<mbj>
Start with String!
<mbj>
cored: I'd change the logic, rather than asking Axiom::Type::Foo what kind of primitive it can handle via .primitive, I'd prefer to use .handle?(primitive)!
<mbj>
So infer would work for both, true and false.
<cored>
ok
<cored>
let me check again
<kapowaz>
solnic: yeah, that could be a cool way of tying it all together
<cored>
mbj: do you guys normally stay on latest version on gems?
<cored>
mbj: I saw that descendant_tracker depends on two gems that are not latest
<solnic>
cored: depends :)
<cored>
rake/yard
<cored>
are the ones
<cored>
never saw this before <=
<cored>
what does it do ?
<cored>
oh
<cored>
he
<cored>
nvm
<cored>
going to step out for a couple of hours
<cored>
later
zirni has joined #rom-rb
<mbj>
cored: devgems?
<cored>
mbj: yes
<mbj>
cored: We typically bump deps once we work on a gem
<cored>
I see
<mbj>
cored: descendants_tracker is stable for so a long time :D
<cored>
well I just saw that on descendent_tracker as I said, was about to upgrade the deps, but wanted to ask
<cored>
yes I noticed that :-)
<mbj>
cored: Feel free to bump!
<cored>
mbj: I tried a new approach for the axiom-types thing, there is a pull request open for me to discuss with dkubb
<cored>
mbj: cool, will do
<mbj>
cored: I saw that PR, but I dont "see" the approach.
<mbj>
cored: you dont set the ivar to reference a type.
<cored>
I just returned Axiom::Types::Boolean instead of Axiom::Attribute::Boolean
<cored>
if the type sent is ::FalseClass
<cored>
now Attribute::Boolean is not needed
<cored>
trying to remove the need of Attribute::* code
<mbj>
cored: A type cannot replace an Axiom::Attribute instance, it does not have a name.