ptico has quit [Remote host closed the connection]
ptico has joined #rom-rb
djsell has quit [Ping timeout: 240 seconds]
ptico has quit [Remote host closed the connection]
djsell has joined #rom-rb
postmodern has quit [Ping timeout: 240 seconds]
djsell has quit [Quit: Leaving.]
postmodern has joined #rom-rb
snusnu has quit [Quit: Leaving.]
kalleth_ has joined #rom-rb
kalleth has quit [Ping timeout: 246 seconds]
{aaron} has joined #rom-rb
<{aaron}>
i guess i'm a total sql noob - joining 40k table w/ 10k table based on an expression is always going to be ridiculously slow?
<{aaron}>
using sqlite to compare against axiom based impl, inner join directly on foreign key is < 1 sec response. but join on a.b_id = (b.id + 1) ... > 265 sec
<mbj>
solnic: We can "share" emitter logic via calling handle with multiple types.
<mbj>
solnic: I think we should reduce all duplication in "dispatch".
<mbj>
solnic: Sometimes nodes can be emitted via the same emitter, but have differend semantics.
<mbj>
solnic: *semantics in another represenation
<solnic>
mbj: ok
<solnic>
mbj: dibe
<solnic>
done even
<mbj>
solnic: sorry for another idea:
<mbj>
solnic: What about renaming assignments to group?
<solnic>
mbj: group?
<solnic>
you mean handle name to be group or class name?
<solnic>
I just removed assignments emitter class and replaced it with delimited emitter like you suggested
<solnic>
group might be confusing with group by
<solnic>
as far as naming goes
<mbj>
solnic: Just collapse the columns and assignments nodes onto pne
<mbj>
*one
<solnic>
into one what?
<mbj>
In ruby you have a :begin node (body)
<solnic>
I already collapse those into delimited emitter
<solnic>
that supports two handles
<mbj>
That gets reused inside def; def self; foo do; etc.
<mbj>
But why we need two handles?
<solnic>
no idea
<solnic>
we don't
<solnic>
but it's more clear when you look at code
<solnic>
I dunno
<mbj>
We should have a standard handle that gets used if you whant to "group" multiple statements.
<solnic>
no strong opinion here
<mbj>
We should create an AST that is also easy to create by a parser.
<solnic>
group is probably not a good idea bkz there's group by
<mbj>
yeah
<mbj>
Lets find a better name!
<mbj>
delimited also
<solnic>
delimited
<mbj>
(bad name)
<solnic>
rite
<solnic>
no
<solnic>
it's good imho
<solnic>
because it is, well, delimited
<solnic>
I will use delimited for now
<mbj>
But it would not make sense from the person writing sexp to generate something
<solnic>
we'll see what dkubb thinks
<mbj>
s(:update, s(:delimited, assignment)....)
<mbj>
go for delimited
<mbj>
we can rename later!
<solnic>
yeah
<solnic>
exactly
<mbj>
solnic: multiple ?
<mbj>
solnic: enumeration ?
snusnu has joined #rom-rb
<solnic>
mbj: too late :P
<solnic>
moving on
<mbj>
solnic: np
<solnic>
mbj: how we should share common stuff between emitters?
<solnic>
mbj: for instance appending WHERE clause is a common thing
<solnic>
both select / update need that
<solnic>
can I just create some module and include it?
<solnic>
or is there some other non-standard convention here?
<mbj>
solnic: Isnt where a dedicated node?
<solnic>
mbj: it is
<solnic>
mbj: I'm talking about that "if where; write(WS); visit(where); end"
<solnic>
flay complains about duplication
<solnic>
however I'm not really sure if we should listen to flay/reek in many cases
<solnic>
this library is specific
<mbj>
solnic: raise the flay score
<solnic>
we don't want to remove duplication in trivial code
<solnic>
because of perf penalty
<mbj>
solnic: for now.
<solnic>
mbj: ok
<solnic>
mbj: wdyt about not running rake ci on travis? it's such a productivity killer when sth is under heavy development
<solnic>
I literally spent an hour total yesterday/today adjusting configs and adding docs
kalleth_ is now known as kalleth
<solnic>
I think we should AT LEAST turn off yardstick
<solnic>
I can live with adjusting reek/flay configs (I think)
<solnic>
but writing tons of redundant talks just to make THE TEST BUILD pass is ridiculous
<solnic>
s/talks/docs/
postmodern has quit [Quit: Leaving]
<solnic>
mbj: I don't think that keeping full docs coverage WHILE developing a library is a reasonable thing to do
<snusnu>
solnic: +1
<mbj>
solnic: Depends on the library, I know the design is unlikely to change for the SQL::Generator namespace
<snusnu>
solnic: and sorry for not yet responding to your email
<mbj>
solnic: Feel free to set yardstick to 0%
<snusnu>
solnic: you know my stance tho
<solnic>
snusnu: I partially forgive you ;)
<snusnu>
heh
<solnic>
mbj: that's not the point
<solnic>
I think preparing for a release should be treated as a separate process
<solnic>
that process shuold include making sure code meets our requirements
<solnic>
which includes full docs coverage
<solnic>
during development it's just a distraction and sth that slows you down
<snusnu>
with docs, imo it is very obvious … i don't care about them while i do development .. for a release, i want them to be perfect
<solnic>
and seeing test build to fail because of that is absolutely too much
<solnic>
snusnu: +1
<mbj>
solnic: feel free to set yardstick bar to 0% :D, this will solve your problem. And we cann
<mbj>
*can do it laters.
<solnic>
no it won't
<solnic>
it would make rake ci pass
<solnic>
I don't want to have it in rake ci
<solnic>
I want to have it in some task that we run prior a release
<snusnu>
yeah, and we don't need travis to automatically *know* if we do ci or not, we're humans after all, WE can decide (if we need to run it locally prior to push)
<solnic>
totally
<solnic>
I'm also on the fence with reek tbh
<solnic>
maintaining its config is a PITA for me
<solnic>
but as I said, I can live with that, for now at least
<snusnu>
solnic: hmm, reek is ok for, actually it still does give me hints
<snusnu>
but
<snusnu>
i also don't need it on travis
<snusnu>
i really hate it when i *know* that a few commits are somewhat WIP, and intermediate builds are broken because i haven't yet adjusted reek config
<snusnu>
or flay/flog for that matter
<snusnu>
i'm totally with solnic tbh … spec+mutant on travis .. the rest for our human brains to decide .. based on common sense
<mbj>
snusnu, solnic: I'm neutral here, talk to dkubb we can change this if he agrees.
<solnic>
yeah me too, tests + mutant on travis
<solnic>
the rest is up to us
<solnic>
frankly I think that CC score is all we need to keep codebases clean
<solnic>
it's not as strict as our settings
<solnic>
but it gives sensible feedback
<snusnu>
well, CC imo is too weak
<snusnu>
without bragging or anything, but i guess recently we all have written very little code that isn't 4.0 ootb .. while we still thought of it as kinda ugly
<solnic>
yeah I guess you're right
<solnic>
CC gives 4.0 too easily
<solnic>
I mean it gives rails > 3.0 which is WEIRD ;P
<snusnu>
hehe
<solnic>
I know it's not nice to pick on sth like that
<solnic>
but it's just a good indicator that it's very gentle with its metrics
<snusnu>
also, it STILL says: Huzzah! This repo has no classes or modules worse than a B. ……..when actually there are only A's :p
<solnic>
haha :)
<snusnu>
when i first saw it i was like, hah, nice bug
<solnic>
mbj: how additional things in select like group by or having should be handled?
<solnic>
mbj: right now we're assuming third child is a where clause
<solnic>
which I guess is not right
<mbj>
solnic: look at the bnf, select is the most complex one.
<solnic>
yes I know
<snusnu>
to sum up my pov on reek: i like it because it allows us to encode our *project* specific preferences .. it therefore somewhat allows to express our "style" .. CC can't, and nothing else i know of can do it as well as reek
<snusnu>
so WE should use it
<snusnu>
not travis
<snusnu>
;)
zekefast has joined #rom-rb
<solnic>
true
<solnic>
well, we should write our own metric tool
<solnic>
err sorry
<solnic>
MBJ should write our own metric tool
<solnic>
:D:D:D
<snusnu>
mwhaha
<snusnu>
for a moment i thought you'd say that we should write our own metric aggregation site ;)
<snusnu>
but i full ack your actual thought too
<snusnu>
hehe
<snusnu>
it'd be ok for that stuff to run on CI, if it wouldn't be allowed to make the build FAIl
<snusnu>
if it only were to post results to some other service, that can be used to review the code and push refactorings accordingly
<snusnu>
i'd much rather have a green travis badge, plus a maybe non green metrics badge
<solnic>
snusnu: that's what I suggested in my email that nobody replied to
<snusnu>
lol i know
<solnic>
:)
<solnic>
the thing with metrics is that it's a feedback mechanism that you must digest yourself and make sense out of it
<snusnu>
it should be easy enough to write that
<snusnu>
yeah
<solnic>
it cannot be used as a way to mark something as working or not
<solnic>
test suite is for that
<solnic>
if tests are green, then everything works (in theory)
<solnic>
metrics "fail" then code needs to be closely reviewed
<snusnu>
maybe we should write that app as "the official" rom demo app?
<solnic>
but it doesn't mean there are bugs
<solnic>
snusnu: yes it crossed my mind
<solnic>
would be sweet
<solnic>
it's kinda funny that the first release of ROM will be with in-memory adapter only
<solnic>
kinda ironic
<solnic>
I already mentioned that
<solnic>
but it's so funny
<solnic>
:D
<snusnu>
hah yeah, it's too awesome :)
<solnic>
I think it's a good move though
<solnic>
make the ball rolling
<snusnu>
the best available
<solnic>
instead of being stuck inside master branch
<snusnu>
also, for the metric badge service, we need no permanent storage
<solnic>
there's a great potential value here - ppl will get involved because something is released and wokring
<solnic>
snusnu: we don't?
<snusnu>
yeah, imo the pitch can be this: *if* you're working on something that will be developed for quite a while, rest assured persistence will work at some point, but in the meantime, enjoy a faster app during development :p
<solnic>
uncle bob style?
<solnic>
:D
<snusnu>
solnic: well, it's not that critical is it? .. we could always serialize the hash to json and write it to disc
<snusnu>
of course
<solnic>
totally
<snusnu>
(re uncle bob style)
<snusnu>
solnic: also, hopefully the app would be stable, so as long as it doesn't crash, we should be good .. for maintenance, we dump the in memory hash to a file
<solnic>
mbj: re select, can you point me in the right direction? basically how to handle children that can include multiple nodes being where, having, group by etc?
<mbj>
solnic: The problem is, we dont need a where node!
<mbj>
solnic: Just a position in the childs that gets a WHERE keyword emitted
<cored>
sorry I meant
<cored>
sooner than later
<cored>
:-P
<mbj>
solnic: if it is non nill
<mbj>
solnic: Just like the case with update!
<mbj>
solnic: We create far to much "useless" nodes, you see this when staring at their dispatch implementation.
<mbj>
solnic: It is already significant a specific child index is non nil, there is no other node that can get plugged at this index.
<mbj>
solnic: Same with group by, it is an index, what you plug there must form a valid expression.
<mbj>
solnic: combined with the keyword GROUP BY
<mbj>
solnic: got my point? In case not, stop now, I'll fix that branch for you!
<mbj>
solnic: That is the problem with not spending 100% of my attention to opensource currently. I only can in, did my blabla and went out, do not have the time to think enough! Sorry!
<cored>
solnic: yesterday you and elskwid told me that some behaviour should still work trying to fix #155
<solnic>
cored: we added a new feature that lets you build a virtus module with its own configuration thus avoiding the need to globally set any configs
<solnic>
however, we did keep the old behavior, which is ability to define default config on the Virtus::Attribute class itself and Virtus module
<cored>
I see
<cored>
but why the need to have two ways of doing the same thing?
<cored>
isn't better to just let one?
<solnic>
cored: because of backward compat
<cored>
oh
<solnic>
I will remove it probably soon
<mbj>
solnic: got my point?
<solnic>
mbj: just pushed
<cored>
solnic: probably is good to add an issue to have it a TODO for later
<solnic>
mbj: but still need to remove those nodes
<solnic>
mbj: so you want me to remove where and group by nodes
<solnic>
and simply use keywords to construct those clauses
<cored>
solnic: and if you guys kept the old behavior; it's weird that this issue exist what you say does exist is exactly that it doesn't work
<mbj>
solnic: jo
<mbj>
solnic: A select without a group by just has "nil" as child of group_by clause index
<solnic>
yes
<mbj>
solnic: A select with group by just has a single delimited node at this index
<solnic>
mbj: but how do you know it is a group by
<solnic>
and not sth else?
<mbj>
solnic: Or in case the parser does not trigger the delimted action a single column expression.
<mbj>
solnic: the index!
<solnic>
so you put nils
<solnic>
explicitly
<solnic>
and you expect specific stuff under specific index
<solnic>
rite?
<mbj>
solnic: jo
<mbj>
solnic: this is how parsing into an ast works.
<solnic>
cored: say what? :)
<mbj>
the ast is a "middleman" you have uglyness from both sides :D
ptico has joined #rom-rb
<solnic>
mbj: I found that ugly so I added those nodes
<solnic>
but if that's how it's supposed to work
<mbj>
solnic: But you'll run into more complex problems when parsing!
<solnic>
I'm totally fine with that
<solnic>
yeah man I trust you here completely
<mbj>
solnic: There is a reason whitequark urged to say: No duplication in the ast.
<cored>
solnic: you said that you guys kept the behavior of globally setting default options on Virtus::Attribute, right?
<mbj>
and the index already tells it is a group by, you dont need a dedicated node
<solnic>
cored: yes we did
<cored>
solnic: but what the issue says contrary, like that doesn't work
<solnic>
cored: well, because it's probably broken right now
<mbj>
solnic: Just following best practises observed when whitequark did his parser. And they make sense.
<solnic>
mbj: sure
<cored>
solnic: can you remember where is the code, I can't find when this happen
<solnic>
cored: look at Virtus::Attribute.coerce
<solnic>
it should set "coerce" option when given a value (true or false)
<solnic>
then it should propagate that option to all descendant attribute classes
<cored>
solnic: checking, the other thing is that the .lazy option is created in runtime
<cored>
solnic: right?
<cored>
solnic: the coerce one work
<cored>
but the lazy one is returning
<cored>
#<Virtus::Attribute::Accessor>
<cored>
and it should return <Virtus::Attribute::Accessor::LazyAccessor>
<mbj>
solnic: Your tweet about my OS commit count gave me 4 new followers.
splattael has quit [Read error: Connection reset by peer]
namelessjon_ has joined #rom-rb
namelessjon has quit [*.net *.split]
ptico has joined #rom-rb
<solnic>
dkubb: interesting fact - mbj pushed more OSS commits during last 12 months than I pushed OSS + non-OSS
<dkubb>
solnic: wow, that's pretty awesome
<dkubb>
I only pushed 4723 commits over the last 12 months
<dkubb>
that's private/public
<cored>
interesting
<cored>
does that contributions implies his own repos?
<dkubb>
although counting commits is like counting LOC. mbj's a machine though
<cored>
I'm intriguite by his over productive behavior
<elskwid>
solnic: I'm glad to hear you compare yourself to him. I was doing the same.
<elskwid>
In fact, as I was eating breakfast I was thinking, HOW?!?
<elskwid>
;)
<cored>
elskwid: I think we all are doing that :-P
<cored>
I started to check other's people profiles too
<elskwid>
Have any of you played with Enums in Ruby? I was toying around with some ideas yesterday.
<elskwid>
meaning, do you use them? Have you created a lib for it? etc.
<elskwid>
cored: Yeah. Once you have something to measure against ...
<cored>
elskwid: Enums, like Java Enums?
<elskwid>
cored: Somewhat. There are times in an application that I want to use Role::MANAGER instead of "manager". Keep the string programmin to a minimum.
<cored>
sure
<cored>
why not just use an struct?
<elskwid>
cored: And I find that very often I have a collection of these "types" like manager, owner, admin, etc and want to list them somewhere. Put a db-friendly version of the string in the DB and map that to a more friendly value.
<elskwid>
cored: Precisely, but as I was playing with it Virtus came to mind. Want to see the WIP gist?
<elskwid>
cored: There were other things I wanted, like being able to iterate over the collection, use some destructuring, and other stuff (like safe chaining)
<cored>
yes
<cored>
always open to read code :-)
<Gibheer>
elskwid: why not load it from the database at the start of the application?
<Gibheer>
there is often stuff which is mostly static and needs only to be loaded at the start of the application, so something like that would make sense
<elskwid>
Gibheer: That seems to be the way people do it. Most "enum" ruby libs are tied to AR and that's more than I need. (or have needed)
<elskwid>
At that point, I don't mind having it in the code-base. It isn't user editable.
<elskwid>
I'd like to move the `.enum` method down into `Types`. It's a partial extraction from something I'm doing in a project now but I went and made it complicated with the Types instance. ha!
<Gibheer>
mostly I used enums only in the case, where it is some kind of attribute with relative low meaning
<Gibheer>
or which I know are really static, like HTTP headers
<Gibheer>
but I never had the need to iterate over them
<elskwid>
Gibheer: I find that it's a common case for me. I'M STUCK IN A RUT!
<elskwid>
ha
<Gibheer>
it looks like too much for me
<elskwid>
Fair enough. I found myself playing with the underlying instance of `Types` and ended up with the method_missing noise. It isn't needed and in a slimmed down version could just go away.
<elskwid>
but yeah just curious if it comes up
<Gibheer>
hmm, why not something like the following: Colors = Enuma.new("Red", "Blue", "Goldenrod", "Burnt Siena")
<Gibheer>
essentially, you don't have to care if the values are mapped to integers or strings or symbols, as long as they don't loose the identity
cored has quit [Ping timeout: 264 seconds]
cored has joined #rom-rb
cored has quit [Changing host]
cored has joined #rom-rb
<Gibheer>
enums are nothing more than a collection of constants, I would say
therabidbanana has quit [Quit: leaving]
<elskwid>
Gibheer: I like that. I was looking at Ara Howard's map too, it would allow you to define the map if you needed. In some cases I find that we have wanted to determine what that integer/symbol/string map key is.
<elskwid>
Gibheer: But that syntax is very nice.
<elskwid>
more stuff for me to play with tonight!
<elskwid>
Gibheer: good point of not worrying about the mapped value.
<cored>
elskwid: did you catch my last msg?
<cored>
elskwid: if not, I just asked if you are planning to add the enum gist to virtus ?
<elskwid>
Gibheer: I was stuck in the mode or replicating the handrolled style where I had to care about the mapped value.
<elskwid>
cored: I didn't see that.
<elskwid>
cored: No, I was thinking that Virtus could do some of what I want to do under the hood. I'm still working that out.
<cored>
I see
<dkubb>
I'm sure an Enum attribute type could be made for virtus
<dkubb>
we did one for DataMapper 1
<elskwid>
dkubb: ah, interesting.
<elskwid>
dkubb: I do like having the Colors::RED used instead of strings. Helps with reading the code and refactoring/reworking too.
<solnic>
elskwid, cored: those stats are a bit confusing - when you look at your own profile you see the total for public+private repost. when you look at other people's profiles you only see their public repo contributions
<solnic>
so, to see your OSS public repo commit count, log out and look at your profile
<elskwid>
solnic: Agreed. The stats are confusing.
<Gibheer>
elskwid: it is pretty easy with that simple API to define the constants too
<elskwid>
Gibheer: yeah. Like I said, I was pretty wrapped up with how I was doing it in my project, where I was just doing it by hand. Your idea has given me alternative which I quite like.
<Gibheer>
if the mapping is important, I think it would also work to also support hashes: Enuma.new("red" => :red, "blue" => 2, "yellow" => Object)
<elskwid>
Gibheer: precisely
<Gibheer>
thats good :)
<Gibheer>
I don't know how hard the following would be: Enuma.new("red", "blue", "foo", {:map_to => Symbol})
<elskwid>
Gibheer: Then you can use it however you like, still have the constants, and iteration.
<Gibheer>
elskwid: it looks interesting
<cored>
solnic: I see mine now
<cored>
:-)
<solnic>
there should be a switch
<solnic>
"include priv repo commits"
<solnic>
or sth
<solnic>
it's confusing now
<cored>
I'm curious about knowing if that's increases commiting to your own repo's
<solnic>
pretty sure it includes commits to your own repos
<elskwid>
solnic: Is it too late for me to jump on that coercer stuff? You guys seem busy with sql at the moment. ;)
<cored>
now I wonder what will happen if I just start a blog about cars a github pages blog with jekyll I totally can mess up my contributions to OSS
<solnic>
elskwid: no why?
<cored>
because they will be just plain text talking about cars
<solnic>
fwiw I'm working on all the things all the time ;P
<elskwid>
solnic: I'm working to free up time every day to do open source. Just making sure it's still a good place to jump in is all.
<elskwid>
solnic: with the timezone I miss some context.
<dkubb>
elskwid: even if some of us are busy with one thing, that shouldn't stop you from working on other areas if you have an interest in them
<cored>
solnic: by the way, I will just take zaizan stuff and put it on rom-rb.org status link without checking that much
<elskwid>
solnic: Ha! All the things. All the time!
<cored>
just checking about style and stuffs like that, is that ok ?
<cored>
elskwid: what time do you have?
<elskwid>
dkubb: No, wasn't my point really. I was more concerned that targets might move since I don't have consistent time on the project. Does that make sense?
<dkubb>
ahh ok
<elskwid>
There's a lot in motion around here. I don't want to confuse an issue or spin cycles if they aren't needed is all.
<elskwid>
Also, I enjoy the hell out of these projects.
<elskwid>
cored: I'm working on that. heh.
<cored>
elskwid: rom-rb.org ?
<cored>
the status section?
<solnic>
elskwid: virtus and coercible are much more stable then rom's libs
<dkubb>
axiom is pretty stable too
<solnic>
true that!
<solnic>
elskwid: so it's easier to contribute to those libs
<dkubb>
there's an outstanding refactoring to integrate axiom-types into axiom if anyone is interested in that
<elskwid>
solnic: That's good to know.
<solnic>
rom-* stuff is gonna settle down soon, but it's in a flux right now
<solnic>
dkubb: same with virtus :)
<Gibheer>
solnic: code faster ;)
<elskwid>
dkubb: Wasn't one of the goals to use axiom-types in coercer?
<elskwid>
heh ^ yeah
<dkubb>
elskwid: I think there was a goal to use axiom-types inside virtus too
mbj has joined #rom-rb
<elskwid>
dkubb: yep
<elskwid>
I should be saying coercible
<dkubb>
even though it has the word "axiom" in it, it's kind of a generic way to define a type
<dkubb>
types are fundamental to relational algebra, which is why I put it in that namespace, but it has utility almost anywhere we declare types.. virtus, axiom, rom
<elskwid>
dkubb: right.
<mbj>
hola
<mbj>
solnic: Great you like SQL generation now!
<elskwid>
Hi mbj
<dkubb>
mbj: hola
<mbj>
dkubb: hi
<mbj>
dkubb: About to run in 5min, anything we need to discuss?
<dkubb>
SQL generation is totally fun.. I love working on that side of things
<dkubb>
mbj: nothing that comes to mind. I'm going to start spiking out the in-memory adapter tonight
<dkubb>
mbj: I'll start with read, which should be trivial, then move onto create, update, delete
<elskwid>
dkubb: I need to get in there and poke around. I've spent so many years working with databases I should be helping.
<mbj>
dkubb: Yeah, feel free to ping me, I'd love to contribute/comment.
<dkubb>
mbj: I'll probably be using a similar design to my new dm-cassandra-adapter, which turned out really nice
<dkubb>
mbj: we're using it in production shortly
<cored>
dkubb: integrating axiom-types into axioms, can you elaborate?
<mbj>
dkubb: You talk about a cql gem?
<dkubb>
mbj: not yet, but I might do that at some later point. CQL is way simpler than SQL
<mbj>
dkubb: So you plan to use a similar design to to dm-cassandra-adapter, similar to axiom?
<dkubb>
cored: so right now, the Axiom::Attribute class represents a couple of things: a named attribute, a type, and constraints. I created axiom-types to represent the type and constraints parts
<dkubb>
mbj: I meant the part where I have command objects for each of the CRUD ops.. not how i'm doing query generation. I won't need to do any query gen in an in-memory adapter since all the relations support the ops natively
<mbj>
dkubb: got it!
<cored>
dkubb: and you want that axioms-types be part of axiom, same code base
<dkubb>
cored: I extracted the type stuff from axiom into https://github.com/dkubb/axiom-types and tested it really well. I think it should be possible to remove the Axiom::Attribute subclasses, and just have an Axiom::Attribute instance that holds the name and type
<dkubb>
cored: I want to keep it as a separate gem, just make it a dependency of axiom
<dkubb>
cored: virtus will probably be using axiom-types, and I wouldn't be surprised if rom-mapper uses it to represent types too
<cored>
dkubb: which means right now axiom have it's own way to use axiom-types but duplicated in the code?
<dkubb>
cored: the ideal case is we could remove all of the classes in https://github.com/dkubb/axiom/tree/master/lib/axiom/attribute .. however, it may be that we need to keep them around to "hang" some fo the axiom functions on, but I think it will probably reduce the type/constraint related logic from all the attribute classes
<dkubb>
cored: what's really interesting is that in DM1 we has Property and Type classes, a Property would have-a Type. I refactored it so the Property was a type. it seemed like a good idea then, but in axiom I have lots of cases where I need to refer to a type without a name (think, when I declare function return types)
<dkubb>
bbiab, lunch
<cored>
wow
mbj has quit [Quit: leaving]
ptico has quit [Remote host closed the connection]
solnic has quit [Quit: Leaving...]
<dkubb>
the reason I need to know a function's return type, is I need to know if it is legal to call a method on it, eg:
<dkubb>
since i know length returns an integer type, I can call gte on it
<dkubb>
if it returned, say, a string then gte would not be legal
<cored>
I see, will take a look at axiom-type
<dkubb>
cored: as a first step, what I was going to do was add the corresponding Axiom::Types::Type subclass inside each Axiom::Attribute subclass inside a class method, and then delegate .primitive and other type related methods to the type, and then work backwards from there
solnic has joined #rom-rb
<cored>
dkubb: hm
<solnic>
dkubb: small correction, I refactored property to be also the type...which was my first commit in dm-core...which basically got be where I am now, here, talking with you all, ha!
<solnic>
s/be/me/
<solnic>
elskwid, cored: re axiom-types, just like dkubb said - virtus and coercible will use axiom-types
<solnic>
rom-mapper will use it too probably
<cored>
solnic: :-)
<cored>
solnic: so the first thing is to make axiom depend on axiom-type and then coersible and virtus depend on axiom ?
<solnic>
cored: nope
<solnic>
cored: axiom, virtus and coercible will depend on axiom-type
ptico has joined #rom-rb
<cored>
oh ok
<cored>
I will check axiom and axiom-type first
<dkubb>
solnic: heh, ahh right, I forgot about that. sorry for taking credit for it..
<dkubb>
solnic: either way, I think it's the wrong model for axiom.. I think it's too much responsibility in Axiom::Attribute
<solnic>
dkubb: no worries! it just reminded me how I got invovled
<solnic>
yeah it's the same in virtus
<solnic>
attribute will be composed of an accessor and type, and type can carry all sorts of info
<solnic>
that's a nice separation
cored has quit [Ping timeout: 256 seconds]
<dkubb>
solnic: the nice thing is type contains one basic piece of information. if you start with the conceptual idea of there being a nearly infinite set of all possible objects, a type basically carves out a subset of that. a type has constraints that allow it to determine if an object is inside the set it represents or not
<cored>
dkubb: here is what I thought about using axiom-types from within axiom
<cored>
taking Boolean attribute from axiom I was about to add Boolean < Axiom::Types::Boolean
<cored>
but I just notice that there are some methods from within axiom that doesn't exist on axiom-types
<dkubb>
cored: that last comment was for solnic, but it was meant for anyone who wants to understand what types is
<cored>
solnic: oh, thanks
<dkubb>
cored: What I would do is start with a has-a relationship between Axiom::Attribute::Boolean and Axiom::Types::Boolean
<cored>
dkubb: got it
<cored>
dkubb: composition over inherantance
<cored>
dkubb: so Axiom::Attribute::Boolean will have a type Axiom::Types::Boolean inside and all it's call will be delegate to it, am I right?
<solnic>
I believe we want to get rid of attribute subclasses
<solnic>
at least I want to remove them in virtus
<solnic>
dkubb: when do you think it would make sense to start integrating axiom-do-adapter with sql?
<solnic>
err axiom-sql-generator
<dkubb>
solnic: I think eventually we *do* want to remove attribute subclasses, but what I'm propsing is a transition step
<solnic>
dkubb: yeah I'd prefer to keep backward compat somehow
<dkubb>
solnic: in axiom I *may* still need subclasses or instances per-type.. or some kind of container, because I need a place to hang axiom type-specific functions
<dkubb>
solnic: like #length on string types or gte, gt, lt, lte on integers, etc
<solnic>
in virtus only embedded attributes will be needed
<solnic>
rest can be removed
* elskwid
reads
<dkubb>
cored: hopefully what I just wrote makes sense. for the refactoring I would 1) start off using composition inside the Axiom::Attribute subclasses, get things working with delegation, 2) make a proxy class that has-a type, and allows us to act as a container for type specific methods like #length on a string, 3) remove Axiom::Attribute subclasses, since with this container we should be able to fulfill their purpose with a type proxy
<cored>
dkubb: send an small fix
<dkubb>
cored: I propose we start off with #1, get it to a working state and then merge it into master before going to #2 or #3.. it doesn't have to be done in a single big PR
<dkubb>
cored: that type is for TrueClass and FalseClass. it's one of the few (only?) type that represents objects with more than one primitive
<cored>
dkubb: I started with Boolean
<cored>
by dfeault Axiom::Types::Boolean return FalseClass
<cored>
but Axiom::Attribute::Boolean.primitive return TrueClass
solnic has joined #rom-rb
zekefast has joined #rom-rb
<dkubb>
cored: one of the differences between axiom and axiom-types is in axiom we ask the Attribute what it's primitive is and match it against an object, and in axiom-types we give the object to the primitive and it tells us if it matches
<zekefast>
Hey, solnic! Congrats! Seems like you have successful fundrazing compaing! ;)
<solnic>
zekefast: yes it's really cool!
<solnic>
zekefast: thanks for donating again :)
<zekefast>
My pleasure! I really believe to ROM and what you do guys here!
<solnic>
:)
<cored>
dkubb: oh
<zekefast>
I want to find time to contribute not only in $ but in action. But need to make my things in proper order first.
<solnic>
zekefast: it's gonna be much easier to contribute code soon
<cored>
dkubb: I see, the only downside on that is that infer_from_primite
<solnic>
things are finally settling down
<cored>
dkubb: is a private method
<dkubb>
cored: so it might not be quite so simple a change. I don't think it's impossible, just a bit more refactoring internally
<cored>
dkubb: in this case which is the better approach ?
<elskwid>
zekefast: Thanks for reminding me!
<zekefast>
yep, I read about first release with in-memory ... that's going to be awesome to look at!
<dkubb>
cored: axiom-types' approach is better, since it allows the type to do whatever it needs to determine if an object is valid
<solnic>
zekefast: we need as many axiom adapters as possible to verify if ROM's design is ready to support various dbs
<solnic>
and doesn't get in your way when you want to support db-specific native features
<cored>
dkubb: in that case two methods will change from withing Axiom::Attribute::Boolean
<cored>
dkubb: one for returning the proper primitive from Axiom::Types and the other one for validating it but using Axiom::Types mechanism also
<cored>
dkubb: the thing is that what infer the primitive type at the moment is a private method
<solnic>
elskwid: srsly? :D thanks man...!
<elskwid>
solnic: Are you kidding me? Of course!
<elskwid>
solnic: I've had a browser tab open for a week!
<elskwid>
ha ha
<solnic>
elskwid: haha :)
<dkubb>
cored: I wouldn't worry so much about what's private or not. the first step is to get something working. we can change interfaces and find the right balance after we have a spike that works
<cored>
dkubb: yes, sure the only thing is that it's blowing on me :-P
<cored>
let me show you, maybe I'm doing something wrong
<dkubb>
cored: can you see where that primitive is being used? perhaps the logic can be changed to pass in the object that is being tested, rather than asking each Axiom::Attribute subclass for it's primitive (of course the name primitive does not match anymore, but I think you knew that)
<cored>
dkubb: trying to find that out now
<cored>
dkubb: I'm guessing you are talking from Axiom point of view, right ?
<dkubb>
cored: yeah. I would rather change axiom to work with axiom-types than the other way around
<cored>
dkubb: got it
cored has quit [Ping timeout: 248 seconds]
cored has joined #rom-rb
zaidan has quit [Quit: leaving]
solnic has quit [Quit: Leaving...]
djsell has quit [Quit: Leaving.]
cored has quit [Ping timeout: 264 seconds]
cored has joined #rom-rb
ptico has quit [Remote host closed the connection]