Re: Type naming conventions: Any_Foo

["Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>]

On 12/7/19 1:05 PM, Niklas Holsti wrote:
> On 2019-12-07 12:19, Jeffrey R. Carter wrote:
>> On 12/6/19 10:55 PM, Niklas Holsti wrote:
>>> On 2019-12-06 22:11, Jeffrey R. Carter wrote:
>>>> On 12/5/19 10:33 PM, Niklas Holsti wrote:
>>>>>
>>>>>     Weapon : Weapon_Id;
>>>>>
>>>>> The variable Weapon does not represent a Weapon; it represents an 
>>>>> identifier of a Weapon, so the name Weapon is IMO a little misleading.
>>>>
>>>> Obviously there are no weapons in the S/W; there are only bit patterns that 
>>>> you have decided to interpret in various ways. But if you're modeling the 
>>>> problem space and it contains something called Weapon, then your software 
>>>> had better have something named Weapon it in, too.
>>>
>>> Agreed.
>>
>> And obviously the thing in the software named Weapon contains a bit pattern 
>> that you interpret as identifying the actual Weapon in the problem space.
> 
> Yes, there may be some "identifier" bits, if (for some reason) Weapons need 
> identifiers.
> 
>> In other words, Weapon contains a Weapon identifier, 
> 
> Possibly, but the internal model of a weapon usually contains much more than 
> just an identifier: it contains bits that define the properties and state of the 
> weapon.
> 
>> and the declaration is not misleading at all.
> 
> If all the program knows of a weapon is its identifier (Weapon_Id), your 
> approach is tolerable (but I still don't like it). If the program has more 
> knowledge of the weapons, so that there is a type Weapon in addition to the type 
> Weapon_Id, I remain firm in my view.

The discussion is whether, given an enumeration named Weapon_Id, the declaration 
above is misleading. Whether the declaration makes sense in a given application 
is irrelevant.

-- 
Jeff Carter
"If you don't get the President of the United States on that
phone, ... you're going to have to answer to the Coca-Cola
Company."
Dr. Strangelove
32