Re: Why is it wrong to have relationships without an inverse in Core Data?
Re: Why is it wrong to have relationships without an inverse in Core Data?
- Subject: Re: Why is it wrong to have relationships without an inverse in Core Data?
- From: Howard Moon <email@hidden>
- Date: Mon, 24 Jun 2013 13:21:09 -0700
Now we're straying off into grammar, but…
How about adding a word to indicate that you're talking about objects, as in "std::map objects" or "multimap objects"?
(I'd rather be clear than save a few keystrokes any day.)
-Howard
On Jun 24, 2013, at 1:00 PM, Alex Zavatone wrote:
> Awesome. Thanks. In today's world, so many people don't seem to pay attention to proper use of the apostrophe, that I thought I'd ask rather than assume.
>
> Noting this, is it wise(r) to actually use (s) to indicate a plural in this case?
>
>
> On Jun 24, 2013, at 9:33 AM, Roland King wrote:
>
>> it's a not-uncommon usage in the programming world where the apostrophe separates the actual name of the thing from the 's' denoting a plural and it means 'more than one std::map'. I've seen this one for years, along with std::map(s) but that takes one extra character to type.
>>
>> On 24 Jun, 2013, at 9:23 PM, Alex Zavatone <email@hidden> wrote:
>>
>>> Scott, your use of the apostrophe is confusing, since those terms don't appear to be possessive or contractions
>>>
>>> Instead of :
>>>> std::map's of
>>>
>>>
>>> and
>>>> multimap's of
>>>
>>>
>>> Did you mean
>>>
>>> std::maps of
>>>
>>> and
>>>
>>> multimaps of ?
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Jun 24, 2013, at 9:06 AM, Scott Ribe wrote:
>>>
>>>> On Jun 23, 2013, at 7:51 PM, Ian Joyner wrote:
>>>>
>>>>> I'd have to do some more thinking as to whether that is a weakness in CoreData or not, but it seems to be erring in the ER direction.
>>>>
>>>> Hmm. My own private ORM has no such pointers--instead using methods which rely on std::map's of primary keys to ids, and multimap's of primary keys to foreign keys...
>>>>
>>>> --
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden