merge comments
Peter Rabbitson [Sat, 25 Aug 2012 22:19:34 +0000 (00:19 +0200)]
TO_MERGE

index 15d1ff3..269ee1b 100644 (file)
--- a/TO_MERGE
+++ b/TO_MERGE
@@ -1,2 +1,33 @@
 The functionality, however, seems fine, though I'd like ribasushi to
 double check it before merging.
+
+* The diff of BelongsTo.pm from master to HEAD currently reads the following
+bollocks:
+
+-  $attrs->{is_foreign_key_constraint} = 1
+-    if not exists $attrs->{is_foreign_key_constraint};
++  $attrs->{relationship_target_owns_me} = 1
++    if not $attrs->{relationship_target_owns_me};
++
++  $attrs->{is_foreign_rel} = 1
++    if not exists $attrs->{is_foreign_rel};
+
+* Generally the default fallback is a check is for boolean not. This makes it
+impossible to pass in an explicit negative. 7fc30cfd82 claims that I requested
+this - I was asking for a change from exists to undef (with the idea that
+passing an undef in would negate an inherited value, and reinvoke the default
+determination)
+
+* I am still firmly on the opinion that relationship_target_owns_me is an
+extremely ugly name. If we want to be both descriptive and fall within a
+sane coherent framework we need to rename the rest. Renaming doesn't mean the
+old names are not supported, it simply means that the docs and examples are
+updated, and that fallbacks for the old names are added in.
+
+owned_by|maybe_owned_by <==> owns_one|maybe_owns_one|owns_many (or perhaps
+                                                     owns_some to indicate 0:M)
+
+Then the logical attr name would be owned_by_target
+
+I won't bikeshed the names anymore, if you elect to merge them this way I
+reserve the right to laugh at you any time a confused soul complains yet again.