<dkubb>
AndrzejKrzywda: there's the allocator which sets the ivars directly, the attribute writer that uses public attribute writers, and the object builder which relies on the constructor accepting a Hash
<dkubb>
AndrzejKrzywda: granted, the allocator breaks encapsulation a bit, but it should work for any object. it's probably the one I will be using most
<dkubb>
snusnu: thanks for the axiom doc commits earlier today
skade has joined #rom-rb
<snusnu>
hey dkubb, i left a comment on GH
<snusnu>
long story short, +1 ;)
<dkubb>
snusnu: my thoughts agree with yours
<snusnu>
sweet :)
<dkubb>
for the same reasons.. the relationship between the two is important
<dkubb>
in jquery I've felt it odd to have some methods where you can do: function(key, value) and function(key: value) . I really wish they would just standardize on the latter
<dkubb>
not only does it express the relationship between the two elements better, it allows for you to provide multiple arguments, and it looks nicer in coffeescript too
<snusnu>
yeah i agree, separating what belongs together always feels weird. it gets even more confusing when you have the option to actually group it together. and not
<snusnu>
and from a pure visual pov, it looks nicer too
<snusnu>
in our particular case, i assume that shortly after using #nest irl, we would've come to suggest a hash anyway. chaining multiple calls to #nest would've soon felt weird, as i totally expect that this will be a very common case
<dkubb>
yeah
mkristian has joined #rom-rb
<snusnu>
dkubb: btw, i actually believe that i will be very happily modeling domains without relationship declarations added anywhere .. i'm thinking it's perfectly valid to model FK constraints in the schema, register whatever virtual (joined) relations, nest them appropriately, and simply inject appropriate mappers into rom relations
<snusnu>
dkubb: that especially holds once we have wrap/unwrap
<snusnu>
dkubb: even if we were to have a "true" relationship concept, i somewhat doubt that i'd be using it
<snusnu>
the only *real/strong* relationships are easily expressed with FK .. everything else is simply transitively walking those strong relationships
travis-ci has joined #rom-rb
<travis-ci>
[travis-ci] dkubb/abstract_type#64 (master - 238631b : Dan Kubb): The build has errored.
<snusnu>
dkubb: just because (probably) every other orm out there has stuff like has_many/belongs_to, it doesn't necessarily mean it's the only way to go .. i more and more believe that a system built on a true DM with RA under the hood, is nicely defined by having a place where all "virtual relations / views on the data" are defined … and then having a set of mappers that fit the data encapsulated in those relations
CraigBuchek has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
<snusnu>
dkubb: there's also the question of *where* to define those relationships anyway … they're meta info, if a PORO really wants to be "pure", all it needs to know is that it has a field named X, only behavior attached to that PORO (and i actually doubt that those POROs will typically have behavior attached in the first place, as imo they are entities/dto's) would semantically (and not defensively) assume that X is, say, an array
<snusnu>
dkubb: so that'd leave us with defining them in some schema object anyway (at least, outside of the POROs themselves)
zekefast has quit [Quit: Leaving.]
<dkubb>
I'm probably going to add wrap/unwrap next too
<snusnu>
dkubb: and inside the schema, imo they don't really fit either, as theoretically, as i said, they're just exploiting strong FK constraints transitively
<snusnu>
dkubb: nice! very nice! ;)
<dkubb>
then I think we can probably model any kind of relationship
<snusnu>
right, what i'm getting at tho, is that we maybe shouldn't .. we could totally leave it up to the users
<snusnu>
at least for some time … build some apps, see where actual relationship declarations would be truly benefitial
<dkubb>
I would like to see it so that people can do arbitrary joins between models as long as the underlying PK/FKs line up
<snusnu>
yeah
<dkubb>
the way joins work in AR is pretty crazy imho, with joins() and includes()
<snusnu>
to elaborate a bit on the style i suggested above .. we modeled our domain totally UI driven, we have simply written down an anima object for every concept we encountered in our UI .. those objects have no behavior, they simply wrap the data .. they're within a namespace of classes that contain the actual behavior (say, Company#add_employee), where Company has access to a rom env (well, actually, it currently mostly uses DM1 models, b
<snusnu>
so essentially we've defined everything we need to get back from the DB, so writing "views/virtual relations" for all those, and then have mappers that build well defined objects, seems to be enough
<snusnu>
i wouldn't know where i would benefit from any line like has_many or belongs_to
<snusnu>
the thing is, if you model your apps differently, and i suggest that you will *have to* do that with a true DM anyway, you start looking at things a bit differently
<snusnu>
imo the schema plays an integral role in a system built around ROM .. it defines base relations, FK and other constraints, and it will contain virtual relations that return useful, properly nested data .. it's a bit of a shift to have virtual relations like "dashboard" which joins a few relations, nests them and stuff .. but i somewhat feel that this is superior to "littering" your domain objects with DSLish stuff related to persisten
<snusnu>
dkubb: i hope that in a few weeks time, i'll be able to push a (very cool) side project of ours to GH, that will be designed that way .. it's probably easier to look at actual application code to discuss advantages/downsides of the approach i outlined above
<dkubb>
I wonder if rubocop could have a magic number detector added
<snusnu>
dkubb: they're simply the data capsules used to "transport" data … the actual domain model, is a different set of objects, which is mostly about behavior, defining it's internal state by those other, behaviorless data capsules
<dkubb>
snusnu: you could almost use axiom tuples too for that I guess?
<snusnu>
dkubb: i'm not too familiar with terminology, but i guess you could call them entities, or dtos
<dkubb>
yeah, I would call those DTOs
<snusnu>
dkubb: i guess so, yes, but i'd somehow loose part of the descriptiveness when doing so
<dkubb>
they've for data transfer.. they basically wrap a primitive and only provide methods to allow creation/unwrapping to be easier, but no real behaviour
<snusnu>
dkubb: right
<dkubb>
snusnu: what kind of descriptiveness would you lose? a named relation with tuples and strong types could probably be just as strong as a DTO.. possibly even stronger since it's got constraints
<snusnu>
dkubb: they provide a nice logical separation tho (well, for me at least) .. they're the stuff we prototype when mocking a UI, give names to domain concepts (just the entities, not state transitions)
<snusnu>
dkubb: this comes before i think about storage
<dkubb>
ahh ok
<snusnu>
they're just domain relevant names, for the data being passed around during state transitions
<snusnu>
i should also note, that my complete app code is based on immutable objects, and state transitions
<snusnu>
so they're names for the data being passed around
<snusnu>
and as a side effect, UIs build up *very* simply, sometimes wrapping them in a presenter, sometimes not
<dkubb>
I suppose you could just use a Struct for that data too
<snusnu>
i definitely could
<snusnu>
but i like the features anima adds
<snusnu>
being stricter
<snusnu>
and adding functional updates e.g
<dkubb>
I've been thinking about using a Struct under Axiom::Tuples
<dkubb>
I would want some kind of struct registry though, because I wouldn't want to create anonymous class objects all over the place that are basically the same
<snusnu>
without doubting the idea, what would be the benefits you'd expect?
<dkubb>
that gets into the messiness of weakrefs and LRU caches
<dkubb>
mostly just using less memory than hashes to represent the same data
<snusnu>
good point
<dkubb>
I believe the method lookups are also faster than hashes
<dkubb>
I mean doing struct_instance.foo is faster than hash[:foo]
<snusnu>
does that "matter" when dealing with so few keys?
<dkubb>
and uses less memory
<snusnu>
ok
<dkubb>
I don't know
<dkubb>
I'd probably need to benchmark it
<dkubb>
I do know Hash and Struct make a difference when you're talking about large sets of data
<dkubb>
even though ROM and axiom are mostly used with small datasets I would still like them to be efficient with larger ones, provided it doesn't increase complexity
<dkubb>
one key with performance is to do as little work as possible. I would see this as fitting in with that
<snusnu>
yes, i agree, if it can be supported, there's no reason not to
<dkubb>
also less memory used, means less GC, which also helps perf
<snusnu>
right
<dkubb>
I may have to deal with the weakref/lru issue soon though because I think sferik wants to do memoization of methods with an arity > 0
<dkubb>
it's basically the same problem
<dkubb>
in fact if I can get it working there, I can have a memoized method that returns the struct.. so I basically get a registry there
<snusnu>
i wanted to ask already .. what's his usecase, do you know? .. i mean, i do realize that from a functional pov, it makes sense .. and in fact, i guess i could/would use it in a few places myself .. in any case, it must be used with care i'd say
<dkubb>
yeah we just have to be really careful
<dkubb>
the memoization can't result in memory leaks
<dkubb>
that would be my #1 requirement for any solution
<dkubb>
which probably means at least a weakref
<dkubb>
and probably some kind of way to make the cache pluggable, so you can use an LRU for long lived objects
<dkubb>
an immutable object being used as a global could get into issues
<dkubb>
or maybe we'll have something like: include Adamantium::Cache::Weakref
<dkubb>
or include Adamantium::Cache::LRU
<dkubb>
with the default being what we currently use which is a threadsafe hash
<dkubb>
from Threadsafe::Hash
<dkubb>
ok, bbiab
dkubb is now known as dkubb|away
mbj has joined #rom-rb
<mbj>
hola
mkristian has quit [Remote host closed the connection]
<snusnu>
mbj: hey
mbj has quit [Ping timeout: 246 seconds]
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]