Type naming conventions: Any_Foo

Type naming conventions: Any_Foo

[Alejandro R. Mosteo]

Hello,

I've recently come across a new (to me) type naming convention and I'm 
curious about how extended it is.

I was aware of the

    Foo.Object -- where Foo is a package and Object is the type name

and

    Foos.Foo -- where Foos is a package and Foo is the type

and

    Foos.Bars -- where both packages and types are in plural

and

    Foo_Type -- where the enclosing package name is not used


This variant is

    Any_Foo -- enclosing package also not used

I've found only one example in the ARM in System.Any_Priority. I find I 
like better Any_Foo than Foo_Type, not sure why. I've had since I can 
remember an aversion for the _Type thing.

Anyway, just curious. Any champions of the Any_Foo in the readership?

Álex.

Re: Type naming conventions: Any_Foo

[Lucretia]

On Wednesday, 4 December 2019 13:56:24 UTC, Alejandro R. Mosteo  wrote:

> This variant is
> 
>     Any_Foo -- enclosing package also not used
> 
> I've found only one example in the ARM in System.Any_Priority. I find I 
> like better Any_Foo than Foo_Type, not sure why. I've had since I can 
> remember an aversion for the _Type thing.
> 
> Anyway, just curious. Any champions of the Any_Foo in the readership?

Not come across this, is this for when "use" is used? What's the name of the package, Foos? Foo?

Re: Type naming conventions: Any_Foo

[Alejandro R. Mosteo]

On 4/12/19 15:52, Lucretia wrote:
> On Wednesday, 4 December 2019 13:56:24 UTC, Alejandro R. Mosteo  wrote:
> 
>> This variant is
>>
>>      Any_Foo -- enclosing package also not used
>>
>> I've found only one example in the ARM in System.Any_Priority. I find I
>> like better Any_Foo than Foo_Type, not sure why. I've had since I can
>> remember an aversion for the _Type thing.
>>
>> Anyway, just curious. Any champions of the Any_Foo in the readership?
> 
> Not come across this, is this for when "use" is used? What's the name of the package, Foos? Foo?

I was ambiguous, sorry. In this case I think the enclosing package is 
secondary. I guess the advantages are the same as in _Type, that you can 
write Foo : Any_Foo;

Re: Type naming conventions: Any_Foo

[AdaMagica]

Of all of these schemes, my favorite is
Package Foos
Type    Any_Foo
Object  Foo

This is tightly related to the discussion predefied types vs. user defined types. It's not always easy, ahem it's often difficult to find good names.

I think finding good names and spending time on this is well spent effort.

I do not know who posted this example a long time ago, but I like it:

Do not use abbreviations. Good names make a program understandable. What is Wpn?

type Weapon_Type is (Broadsword, Catapult, Bow_and_Arrow);

procedure Attack_Using (Weapon: Weapon_Type);

Weapon: Weapon_Type;

Attack_Using (Weapon => Catapult);  -- a bit talkative
Attack_Using (Catapult);  -- good only with positional association

versus

type Weapon is (Broadsword, Catapult, Bow_and_Arrow);

procedure Attack (Using: Weapon);

My_Weapon, Foes_Weapon: Weapon;

Attack (Using => Catapult);  -- good only with named association
Attack (Catapult);  -- Do we attack the catapult or what?

Re: Type naming conventions: Any_Foo

[Jeffrey R. Carter]

On 12/5/19 11:51 AM, AdaMagica wrote:
> 
> (Broadsword, Catapult, Bow_and_Arrow);

There are 2 ways to look at them:

1. These identify the possible weapons: Weapon_ID
2. These are the names of the possible weapons: Weapon_Name

Either of these are better than any name derived using a convention, while still 
leaving the best name (weapon) available for parameter names. This because they 
were created by thinking (which is what S/W engineers are paid to do), while 
conventions exist to allow developers to avoid thinking.

I would even say that those who use naming conventions such as _T[y[p[e]]] are 
either not S/W engineers or are shirking their duties.

-- 
Jeff Carter
"Ada has made you lazy and careless. You can write programs in C that
are just as safe by the simple application of super-human diligence."
E. Robert Tisdale
72

Re: Type naming conventions: Any_Foo

[Dmitry A. Kazakov]

On 2019-12-05 18:27, Jeffrey R. Carter wrote:

> I would even say that those who use naming conventions such as 
> _T[y[p[e]]] are either not S/W engineers or are shirking their duties.

There exist cases:

1. Formal generic types. They are customarily named XXX_Type.

2. Types which are artifacts of language issues or of design. These have 
no separate problem space meaning and thus no meaningful name. E.g.

    type Something is ...;
    type Something_Ptr is access Something;
       -- I don't want access type, I am required to have it 


BTW, this includes all sorts of helper types Ada kept introducing recently.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Type naming conventions: Any_Foo

[Jeffrey R. Carter]

On 12/5/19 6:45 PM, Dmitry A. Kazakov wrote:
> 
> 1. Formal generic types. They are customarily named XXX_Type.

Well chosen names for generic formal types do not end with _Type. The PragmAda 
Reusable Components have many generic formal types, none of which end with _Type.

>        -- I don't want access type, I am required to have it

Please provide examples of being required to have an access type.

-- 
Jeff Carter
"Ada has made you lazy and careless. You can write programs in C that
are just as safe by the simple application of super-human diligence."
E. Robert Tisdale
72

Re: Type naming conventions: Any_Foo

[Dmitry A. Kazakov]

On 2019-12-05 21:03, Jeffrey R. Carter wrote:
> On 12/5/19 6:45 PM, Dmitry A. Kazakov wrote:
>>
>> 1. Formal generic types. They are customarily named XXX_Type.
> 
> Well chosen names for generic formal types do not end with _Type. The 
> PragmAda Reusable Components have many generic formal types, none of 
> which end with _Type.

Ada standard library uses _Type, e.g.

generic
    type Element_Type (<>) is private;
    with function "=" (Left, Right : Element_Type) return Boolean is <>;
package Ada.Containers.Indefinite_Holders

As I said, the rationale is that there is no meaningful name for 
Element_Type in the problem space. There is no problem space at all. 
Indefinite_Holders is a helper package so general that considered in 
isolation it has no meaning.

>>        -- I don't want access type, I am required to have it
> 
> Please provide examples of being required to have an access type.

There are lots of cases in Ada, you certainly should know that. As a 
practical example GtkAda declares all widget types twice:

    type Gtk_Button_Record is ...
    type Gtk_Button is access all Gtk_Button_Record'Class;

The suffix _Record is an equivalent to _Type.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Type naming conventions: Any_Foo

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:qsbu56$18iv$1@gioia.aioe.org...
> On 2019-12-05 21:03, Jeffrey R. Carter wrote:
...
> There are lots of cases in Ada, you certainly should know that. As a 
> practical example GtkAda declares all widget types twice:
>
>    type Gtk_Button_Record is ...
>    type Gtk_Button is access all Gtk_Button_Record'Class;
>
> The suffix _Record is an equivalent to _Type.

This is the only case where I've used "Any_" as a type prefix, in Claw --  
specifically, class-wide access types.

    type Root_Window_Type is abstract tagged private;

    type Any_Window_Access_Type is access all Root_Window_Type'Class;

Access-to-classwide is a different sort of thing than access-to-specific, 
and I wanted a different sort of name for it.

For Claw, we tried to use a set of consistent prefixes and suffixes for 
declarations. We needed to get away from the terrible Hungarian names of 
Win32, but given that packages were constructed by many members of a team 
and needed a strong level of consistency, just letting everyone pick names 
was not going to be a good idea.

Jeff Carter wrote:
> I would even say that those who use naming conventions such as _T[y[p[e]]] 
> are either not S/W engineers or are shirking their duties.

I'm presuming this is typical Internet Hyperbole, as I don't think you can 
seriously say that about the designers of the Ada 83 runtime, large 
resusable sets of packages like Claw and GTK, and many others. There is an 
important value to consistency of naming in large projects, and picking 
names by "thinking", as Jeff puts it, is not going to result in that 
consistency.

Janus/Ada uses names picked Jeff's way (mostly, I've adopted the Claw rules 
for new things), and it is hard to figure out the name of something when you 
don't remember it. And an Ada compiler has a *lot* of declarations; it's 
hard to even find them in the package specs if you can't remember enough 
about the possible name for a search to work. (Janus/Ada's root go back to 
the fall of 1980, so it's common to not remember something! :-).

                                    Randy.

Re: Type naming conventions: Any_Foo

[Jeffrey R. Carter]

On 12/6/19 12:12 AM, Randy Brukardt wrote:
> 
> Janus/Ada uses names picked Jeff's way (mostly, I've adopted the Claw rules
> for new things), and it is hard to figure out the name of something when you
> don't remember it. And an Ada compiler has a *lot* of declarations; it's
> hard to even find them in the package specs if you can't remember enough
> about the possible name for a search to work. (Janus/Ada's root go back to
> the fall of 1980, so it's common to not remember something! :-).

I don't see how adding _Type to the end of a name makes the part that comes 
before _Type any easier to remember.

-- 
Jeff Carter
"Brave Sir Robin ran away."
Monty Python and the Holy Grail
59

Re: Type naming conventions: Any_Foo

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:qsed5s$93u$2@dont-email.me...
> On 12/6/19 12:12 AM, Randy Brukardt wrote:
>>
>> Janus/Ada uses names picked Jeff's way (mostly, I've adopted the Claw 
>> rules
>> for new things), and it is hard to figure out the name of something when 
>> you
>> don't remember it. And an Ada compiler has a *lot* of declarations; it's
>> hard to even find them in the package specs if you can't remember enough
>> about the possible name for a search to work. (Janus/Ada's root go back 
>> to
>> the fall of 1980, so it's common to not remember something! :-).
>
> I don't see how adding _Type to the end of a name makes the part that 
> comes before _Type any easier to remember.

For me at least, it lets me keep the operative names much shorter and freer 
of junk prefixes. Shorter names are easier to find because one doesn't get 
confused about whether the type is Root_Window or Window_Root or 
Root_of_Window. And the _Type keeps them from being too short.

                                                 Randy.

Re: Type naming conventions: Any_Foo

[Jeffrey R. Carter]

On 12/5/19 10:51 PM, Dmitry A. Kazakov wrote:
> 
> Ada standard library uses _Type, e.g.
> 
> generic
>     type Element_Type (<>) is private;
>     with function "=" (Left, Right : Element_Type) return Boolean is <>;
> package Ada.Containers.Indefinite_Holders

Yes, and the ARM also includes such abominations as anonymous access types. Just 
because it's in the ARM doesn't mean it's the best way to do something. Element 
is be a better name for that formal type.

> There are lots of cases in Ada, you certainly should know that. As a practical 
> example GtkAda declares all widget types twice:
> 
>     type Gtk_Button_Record is ...
>     type Gtk_Button is access all Gtk_Button_Record'Class;

No well designed library has public access types. You aren't required to use a 
library that does, and you aren't required to use access types.

-- 
Jeff Carter
"Brave Sir Robin ran away."
Monty Python and the Holy Grail
59

Re: Type naming conventions: Any_Foo

[Dmitry A. Kazakov]

On 2019-12-06 21:18, Jeffrey R. Carter wrote:
> On 12/5/19 10:51 PM, Dmitry A. Kazakov wrote:
>>
>> Ada standard library uses _Type, e.g.
>>
>> generic
>>     type Element_Type (<>) is private;
>>     with function "=" (Left, Right : Element_Type) return Boolean is <>;
>> package Ada.Containers.Indefinite_Holders
> 
> Yes, and the ARM also includes such abominations as anonymous access 
> types. Just because it's in the ARM doesn't mean it's the best way to do 
> something. Element is be a better name for that formal type.

No, it would be misleading. Element must be reserved for instances of 
the type. They are actual elements. The type of an element is not an 
element, these are two totally different things.

>> There are lots of cases in Ada, you certainly should know that. As a 
>> practical example GtkAda declares all widget types twice:
>>
>>     type Gtk_Button_Record is ...
>>     type Gtk_Button is access all Gtk_Button_Record'Class;
> 
> No well designed library has public access types. You aren't required to 
> use a library that does, and you aren't required to use access types.

I am required to. There must be always be two types in a GUI, one 
referential type and one implementation type. The widget implementation 
object in GtkAda is Gtk_Button_Record. The widget referential object is 
Gtk_Button. It could be a handle or a smart pointer type instead of 
plain pointer, but there is no way to reduce it to a single type. So the 
problem will persist.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Type naming conventions: Any_Foo

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:qsee2v$par$1@gioia.aioe.org...
> On 2019-12-06 21:18, Jeffrey R. Carter wrote:
>> On 12/5/19 10:51 PM, Dmitry A. Kazakov wrote:
>>>
>>> Ada standard library uses _Type, e.g.
>>>
>>> generic
>>> type Element_Type (<>) is private;
>>> with function "=" (Left, Right : Element_Type) return Boolean is <>;
>>> package Ada.Containers.Indefinite_Holders
>>
>> Yes, and the ARM also includes such abominations as anonymous access 
>> types. Just because it's in the ARM doesn't mean it's the best way to do 
>> something. Element is be a better name for that formal type.
>
> No, it would be misleading. Element must be reserved for instances of the 
> type. They are actual elements. The type of an element is not an element, 
> these are two totally different things.

Agreed. Ada.Containers all have a function Element that retrieves a (copy 
of) a single element object from the container. If the type was named 
element, what would this function be called? Similarly, some of the 
parameters are called Element (thus, Element : Element_Type in many 
parameter lists); those also would need alternate names.

There were a number of ARG members that disliked the "_Type" notation, so we 
looked at alternatives. And we didn't find anything that worked as well. 
Sometimes, package design is about the "least bad" alternative.

                                     Randy.




>>> There are lots of cases in Ada, you certainly should know that. As a 
>>> practical example GtkAda declares all widget types twice:
>>>
>>> type Gtk_Button_Record is ...
>>> type Gtk_Button is access all Gtk_Button_Record'Class;
>>
>> No well designed library has public access types. You aren't required to 
>> use a library that does, and you aren't required to use access types.
>
> I am required to. There must be always be two types in a GUI, one 
> referential type and one implementation type. The widget implementation 
> object in GtkAda is Gtk_Button_Record. The widget referential object is 
> Gtk_Button. It could be a handle or a smart pointer type instead of plain 
> pointer, but there is no way to reduce it to a single type. So the problem 
> will persist.
>
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de 

Re: Type naming conventions: Any_Foo

[Jeffrey R. Carter]

On 12/7/19 1:57 AM, Randy Brukardt wrote:
> 
> Agreed. Ada.Containers all have a function Element that retrieves a (copy
> of) a single element object from the container. If the type was named
> element, what would this function be called? Similarly, some of the
> parameters are called Element (thus, Element : Element_Type in many
> parameter lists); those also would need alternate names.

At a conference long ago (probably in the Ada-83 days), a presenter claimed that 
well designed Ada has 90% of its operations named Put or Get. Get is an 
appropriate name for such an operation.

More specifically, good names may depend on the data structure. When the normal 
Get operation modifies the structure, as for queues and stacks, Peek is a good 
name. Value is a good name for most other cases.

Parameters of the type should be named Item.

-- 
Jeff Carter
"C++ is like jamming a helicopter inside a Miata
and expecting some sort of improvement."
Drew Olbrich
51

Re: Type naming conventions: Any_Foo

[Niklas Holsti]

On 2019-12-07 12:28, Jeffrey R. Carter wrote:
> On 12/7/19 1:57 AM, Randy Brukardt wrote:
>>
>> Agreed. Ada.Containers all have a function Element that retrieves a (copy
>> of) a single element object from the container. If the type was named
>> element, what would this function be called? Similarly, some of the
>> parameters are called Element (thus, Element : Element_Type in many
>> parameter lists); those also would need alternate names.
> 
> At a conference long ago (probably in the Ada-83 days), a presenter 
> claimed that well designed Ada has 90% of its operations named Put or 
> Get.

Horror. The result of blind OO convention :-)

> Get is an appropriate name for such an operation.

I follow the convention that procedure names are verbs ("Get") or verb 
phrases ("Remove_Last_Item") that describe the action or its effects, 
while function names are nouns ("Element") or noun phrases 
("Largest_Element") that describe the value returned by the function.

Therefore, IMO, "Get" is not a proper name for a function (unless the 
program models animal breeding, and the Get function returns all the 
offspring of a particular animal or pair of animals).

> More specifically, good names may depend on the data structure. When the 
> normal Get operation modifies the structure, as for queues and stacks, 
> Peek is a good name.

For stacks, Push and Pop.

For queues, Enqueue and Dequeue.

Functions should usually not modify their parameter structures; I use 
procedures for that.

> Value is a good name for most other cases.

Sometimes, but often it is too general. And it it ambiguous, because it 
can also mean "worth" or "usefulness".

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Type naming conventions: Any_Foo

[Jeffrey R. Carter]

On 12/7/19 1:36 PM, Niklas Holsti wrote:
> 
> I follow the convention that procedure names are verbs ("Get") or verb phrases 
> ("Remove_Last_Item") that describe the action or its effects, while function 
> names are nouns ("Element") or noun phrases ("Largest_Element") that describe 
> the value returned by the function.
> 
> Therefore, IMO, "Get" is not a proper name for a function (unless the program 
> models animal breeding, and the Get function returns all the offspring of a 
> particular animal or pair of animals).

I agree, but functions named starting with Get_ are common enough in the ARM 
that we are stuck with them.

-- 
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

Re: Type naming conventions: Any_Foo

[Jeffrey R. Carter]

On 12/6/19 9:35 PM, Dmitry A. Kazakov wrote:
> 
> No, it would be misleading. Element must be reserved for instances of the type. 
> They are actual elements. The type of an element is not an element, these are 
> two totally different things.

As these are generic data structures, there are no instances of the type. 
Parameters should be called Item (the library commonly uses New_Item).

> I am required to. There must be always be two types in a GUI, one referential 
> type and one implementation type. 

As I have presented here in the past a proof of concept of a GUI library that 
uses no access types, this is demonstrably false.

-- 
Jeff Carter
"C++ is like jamming a helicopter inside a Miata
and expecting some sort of improvement."
Drew Olbrich
51

Re: Type naming conventions: Any_Foo

[Dmitry A. Kazakov]

On 2019-12-07 11:13, Jeffrey R. Carter wrote:
> On 12/6/19 9:35 PM, Dmitry A. Kazakov wrote:
>>
>> No, it would be misleading. Element must be reserved for instances of 
>> the type. They are actual elements. The type of an element is not an 
>> element, these are two totally different things.
> 
> As these are generic data structures, there are no instances of the 
> type.

Each type has instances = objects of.

> Parameters should be called Item (the library commonly uses 
> New_Item).

That is a poor choice of names. What is the difference or connection 
between Element and Item. How the type of Item is Element? Why not 
otherwise? To me the pair Element_Type-Element is cleaner than Element-Item.

[ Element and item are just same thing. Element is a member of a set. 
Item is a member of a set too, though the set is usually ordered. ]

>> I am required to. There must be always be two types in a GUI, one 
>> referential type and one implementation type. 
> 
> As I have presented here in the past a proof of concept of a GUI library 
> that uses no access types, this is demonstrably false.

Yes, I remember you did, but I also remember that it was not really usable.

The fact is that widgets have referential semantics because they are not 
computational objects, they live in the outer world like all I/O 
objects, e.g. File_Type (Note "_Type" (:-)). You cannot get around that.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Type naming conventions: Any_Foo

[Jeffrey R. Carter]

On 12/7/19 12:21 PM, Dmitry A. Kazakov wrote:
> On 2019-12-07 11:13, Jeffrey R. Carter wrote:
>>
>> As these are generic data structures, there are no instances of the type.
> 
> Each type has instances = objects of.

I have seen a generic data structure named Generic_B_Trees, written by Dimitry 
Kazakov. It has 2 generic formal types, and no instances of either of those types.

>> As I have presented here in the past a proof of concept of a GUI library that 
>> uses no access types, this is demonstrably false.
> 
> Yes, I remember you did, but I also remember that it was not really usable.

I implemented several examples using the it, and found it quite usable, and the 
resulting code much easier to understand than typeical GUIs.

However, the point in contention was your claim that you are required to use 
access types to have a GUI. When that was demonstrated to be untrue, you 
attempted to change the subject. So I consider this discussion finished.

-- 
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

Re: Type naming conventions: Any_Foo

[Dmitry A. Kazakov]

On 2019-12-08 12:55, Jeffrey R. Carter wrote:
> On 12/7/19 12:21 PM, Dmitry A. Kazakov wrote:
>> On 2019-12-07 11:13, Jeffrey R. Carter wrote:
>>>
>>> As these are generic data structures, there are no instances of the 
>>> type.
>>
>> Each type has instances = objects of.
> 
> I have seen a generic data structure named Generic_B_Trees, written by 
> Dimitry Kazakov. It has 2 generic formal types, and no instances of 
> either of those types.

I am not sure what your point is. The formal type is not a type. It is a 
class, set of types. An actual type of the formal type is a proper type. 
Both have instances. The instances of a formal type are types. The 
instances of a type are object of.

My point is that calling a class or a singular type Element is not good.

>>> As I have presented here in the past a proof of concept of a GUI 
>>> library that uses no access types, this is demonstrably false.
>>
>> Yes, I remember you did, but I also remember that it was not really 
>> usable.
> 
> I implemented several examples using the it, and found it quite usable, 
> and the resulting code much easier to understand than typeical GUIs.

In my view it lacks fundamental GUI elements like aggregation of 
widgets, hierarchical organization of events and event handling, classes 
of widgets.

I don't see how these can be solved without references. I hate pointers, 
but I doubt that the references required for GUI can be made 
significantly safer than pointers in Ada, presently.

And the reference types must have separate names anyway, again 
presently. [ I could imagine some attribute to denote corresponding type 
anonymously, like T'Class does, but that is not Ada. ]

> However, the point in contention was your claim that you are required to 
> use access types to have a GUI. When that was demonstrated to be untrue, 
> you attempted to change the subject. So I consider this discussion 
> finished.

OK

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Type naming conventions: Any_Foo

[Shark8]

On Sunday, December 8, 2019 at 4:55:57 AM UTC-7, Jeffrey R. Carter wrote:
> 
> >> As I have presented here in the past a proof of concept of a GUI library that 
> >> uses no access types, this is demonstrably false.
> > 
> > Yes, I remember you did, but I also remember that it was not really usable.
> 
> I implemented several examples using the it, and found it quite usable, and the 
> resulting code much easier to understand than typeical GUIs.
> 
> However, the point in contention was your claim that you are required to use 
> access types to have a GUI. When that was demonstrated to be untrue, you 
> attempted to change the subject. So I consider this discussion finished.

I'm rather interested in this no-access-type library idea.
Would it be easier to do with, say, an Ada implementation of Display PostScript?

Re: Type naming conventions: Any_Foo

[Jeffrey R. Carter]

On 12/8/19 3:31 PM, Shark8 wrote:
> 
> I'm rather interested in this no-access-type library idea.
> Would it be easier to do with, say, an Ada implementation of Display PostScript?

That might work, though I thought there were licensing issues with using 
PostScript. I've heard that Apple does something similar with PDF because anyone 
is allowed to produce PDF, but not PostScript.

I would probably choose HTML5 for portability.

-- 
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

Re: Type naming conventions: Any_Foo

[Shark8]

On Sunday, December 8, 2019 at 2:58:21 PM UTC-7, Jeffrey R. Carter wrote:
> On 12/8/19 3:31 PM, Shark8 wrote:
> > 
> > I'm rather interested in this no-access-type library idea.
> > Would it be easier to do with, say, an Ada implementation of Display PostScript?
> 
> That might work, though I thought there were licensing issues with using 
> PostScript.
There might have been, at one point; but IIUC Adobe made the language-spec/RM free to download... which means we could implement it ourselves; this, in turn, means that we could implement it without [exposed] access types. -- IIRC, it's been a while since I've read the spec.

> I've heard that Apple does something similar with PDF because anyone 
> is allowed to produce PDF, but not PostScript.
Maybe; I seem to recall PDF was pushed to ISO-standardization, but might be misremembering.

> I would probably choose HTML5 for portability. 
Well, that's basically Gnoga's approach. I was thinking more of going the other way: using this for a system's base itself. (Possibly being able to share things with other Ada projects; e.g. the Wasabee web-browser.)

Re: Type naming conventions: Any_Foo

[Jere]

On Saturday, December 7, 2019 at 5:13:24 AM UTC-5, Jeffrey R. Carter wrote:
> On 12/6/19 9:35 PM, Dmitry A. Kazakov wrote:
> 
> > I am required to. There must be always be two types in a GUI, one referential 
> > type and one implementation type. 
> 
> As I have presented here in the past a proof of concept of a GUI library that 
> uses no access types, this is demonstrably false.
> 

You are correct that you can write a high level abstraction wrapper
around a GUI without exposing access types, but to Dmitry's point, the
actual code that creates the GUI components has to use access types
or some sort of referential data type.  Your example GUI illustrates even
this.  When you look at ada_gui.adb, you will see multiple uses of 
access types:  accesses to procedure callbacks, accesses to GUI components,
uses of 'Access, etc. 

So if you are simply writing a wrapper around a GUI library, sure, but if
you are writing an actual GUI library, I'm not sure it can be done without
them.  I would definitely like to see your code if you can write an
actual GUI library without them at all.  The one you have posted on github
still has access types used in it.  You are correct that you can hide 
them at the high level though.

Re: Type naming conventions: Any_Foo

[Jeffrey R. Carter]

On 12/8/19 12:24 AM, Jere wrote:
> 
> You are correct that you can write a high level abstraction wrapper
> around a GUI without exposing access types, but to Dmitry's point, the
> actual code that creates the GUI components has to use access types
> or some sort of referential data type.  Your example GUI illustrates even
> this.  When you look at ada_gui.adb, you will see multiple uses of
> access types:  accesses to procedure callbacks, accesses to GUI components,
> uses of 'Access, etc.

The implementation of Ada_GUI is a hack to let me test the feasibility of the 
idea. I think a real implementation could be done without needing access types, 
but have not looked into it in enough detail to be sure. Even if it cannot be 
implemented without them, this discussion was about what the pkg requires from 
its clients, so the implementation 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

Re: Type naming conventions: Any_Foo

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:qsipel$t3k$1@dont-email.me...
> On 12/8/19 12:24 AM, Jere wrote:
>>
>> You are correct that you can write a high level abstraction wrapper
>> around a GUI without exposing access types, but to Dmitry's point, the
>> actual code that creates the GUI components has to use access types
>> or some sort of referential data type.  Your example GUI illustrates even
>> this.  When you look at ada_gui.adb, you will see multiple uses of
>> access types:  accesses to procedure callbacks, accesses to GUI 
>> components,
>> uses of 'Access, etc.
>
> The implementation of Ada_GUI is a hack to let me test the feasibility of 
> the idea. I think a real implementation could be done without needing 
> access types, but have not looked into it in enough detail to be sure. 
> Even if it cannot be implemented without them, this discussion was about 
> what the pkg requires from its clients, so the implementation is 
> irrelevant.

To me, this is the key point. Claw uses very few access types externally; 
the user view is generally one of objects, which can be aggregated in any 
way the user desires (records, arrays, containers, or allocation/access 
types). There were a few places where that model didn't work, although I 
think that was more because of the underlying system (Win32) and wanting to 
make all of the facilities available in some way, rather than because it was 
strictly necessary.

Note that most Claw types are non-limited (thus allowing "cloning" - a copy 
being a "clone" of the original, and more importantly, return from 
functions) and task safe in the same way as Ada (so long as a single task 
only operates on a single object, everything will work -- tasks can work on 
different clones of the same underlying object).

                             Randy.

Re: Type naming conventions: Any_Foo

[Niklas Holsti]

On 2019-12-05 19:27, Jeffrey R. Carter wrote:
> On 12/5/19 11:51 AM, AdaMagica wrote:
>>
>> (Broadsword, Catapult, Bow_and_Arrow);
> 
> There are 2 ways to look at them:
> 
> 1. These identify the possible weapons: Weapon_ID
> 2. These are the names of the possible weapons: Weapon_Name

Either of those is itself defining a convention. It seems every 
enumerated type would then get an "_ID" or "_Name" suffix. Or something 
similar.

In my programs, it is very often the case that some object both has a 
type, and has an (internal) identifier, and has an (external) name. So 
the identifiers Weapon_ID and Weapon_Name would be suitable for those 
other types, but not for the Weapon type/concept itself.

> I would even say that those who use naming conventions such as 
> _T[y[p[e]]] are either not S/W engineers or are shirking their duties.

Ouch (I use the "_T" convention).

As an alternative to the "_T" convention, I could consider using longer, 
compound names for formal parameters, for example

   procedure Kill (With_Weapon : in Weapon)

I often use such compounds also with the "_T" convention. Unfortunately, 
I have found that this often leads to rather artificial and 
hard-to-remember compounds, and is even harder to apply sensibly to 
local variables (as opposed to formal parameters). So I go with "_T".

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Type naming conventions: Any_Foo

[Jeffrey R. Carter]

On 12/5/19 8:49 PM, Niklas Holsti wrote:
> 
> Either of those is itself defining a convention. It seems every enumerated type 
> would then get an "_ID" or "_Name" suffix. Or something similar.

Many enumeration types are identifiers or names; some are not. A convention 
would end every enumeration type name with the same suffix, even when it's not 
appropriate. Well chosen type names would perhaps result in many such names 
ending in the same suffix, but not all.

As an example, the PragmAda Reusable Components have 13 lines returned by

grep -i "type  *[a-z0-9_]*  *is  *(" *.ad?

8 of them end in _I[Dd] (I really should make the casing consistent), 1 in 
_Name, and 4 others. Had I used the convention of _ID rather than making the 
effort to think of good names, about 1/3 of those names would be less 
meaningful. Had I used a meaningless convention like _T for all type names, all 
of those names would be less meaningful. Meaningful names are easier to read, 
and ease of reading is an important goal of S/W engineering.

-- 
Jeff Carter
"Ada has made you lazy and careless. You can write programs in C that
are just as safe by the simple application of super-human diligence."
E. Robert Tisdale
72

Re: Type naming conventions: Any_Foo

[Niklas Holsti]

On 2019-12-05 22:47, Jeffrey R. Carter wrote:
> On 12/5/19 8:49 PM, Niklas Holsti wrote:
>>
>> Either of those is itself defining a convention. It seems every 
>> enumerated type would then get an "_ID" or "_Name" suffix. Or 
>> something similar.
> 
> Many enumeration types are identifiers or names; some are not.

I don't really agree with that "many", but it is perhaps a subjective 
issue -- how one thinks of an enumeration.

But if a value of the type Weapon_Id is an identifier of a Weapon, how 
can you defend saying

    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.

> A convention would end every enumeration type name with the same suffix, 
> even when it's not appropriate. Well chosen type names would perhaps 
> result in many such names ending in the same suffix, but not all.
> 
> As an example, the PragmAda Reusable Components have 13 lines returned by
> 
> grep -i "type  *[a-z0-9_]*  *is  *(" *.ad?
> 
> 8 of them end in _I[Dd] (I really should make the casing consistent), 1 
> in _Name, and 4 others.

Thanks for sharing this statistic.

(And yes, the issue of "ID" vs "Id" is a wide-spread annoyance. I tend 
to think that "ID" is an acronym for "Identification Document", while 
"Id" is an abbreviation for "Identifier". Obviously "Id" is more often 
apt for SW.)

> Had I used the convention of _ID rather than making the effort to
> think of good names, about 1/3 of those names would be less
> meaningful.
I agree with that, of course.

> Had I used a meaningless convention like _T for all 
> type names, all of those names would be less meaningful.

I don't agree with that, and of course I would include "_Id" or "_Name" 
or whatever is appropriate and meaningful, before the "_T".

> Meaningful names are easier to read, and ease of reading is an
> important goal of  S/W engineering.

Hell yes. But for me, the "_T" helps that goal, by letting me say either

    Weapon : Weapon_T;

or

    Weapon_Id : Weapon_Id_T;

depending on the case at hand.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Type naming conventions: Any_Foo

[Lucretia]

On Thursday, 5 December 2019 21:33:55 UTC, Niklas Holsti  wrote:

> Hell yes. But for me, the "_T" helps that goal, by letting me say either
> 
>     Weapon : Weapon_T;

I used to use the _T, but now I use plural/singular for package/type names.
 
> or
> 
>     Weapon_Id : Weapon_Id_T;
> 
> depending on the case at hand.

An alternative for enumerations would be:

   type All_Weapons is (Broadsword, Catapult, Bow_and_Arrow);

   Weapon : All_Weapons := Broadsword;

But this does look a bit weird, maybe a renaming of All_Weapons to A_Weapon would make the variable definition look better?

   Weapon : A_Weapon := Broadsword;

Luke.

Re: Type naming conventions: Any_Foo

[Jeffrey R. Carter]

On 12/6/19 12:44 PM, Lucretia wrote:
> 
>     type All_Weapons is (Broadsword, Catapult, Bow_and_Arrow);

It has been demonstrated that the first few characters of an identifier are the 
most important in distinguishing them; having lots of identifiers with the same 
first few characters makes the code harder to read. So common prefixes are even 
worse that suffixes.

-- 
Jeff Carter
"Brave Sir Robin ran away."
Monty Python and the Holy Grail
59

Re: Type naming conventions: Any_Foo

[Jeffrey R. Carter]

On 12/5/19 10:33 PM, Niklas Holsti wrote:
> 
> But if a value of the type Weapon_Id is an identifier of a Weapon, how can you 
> defend saying
> 
>     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.

I would probably write something like

type Character_Info is record
    ...
    Available_Weapons : Weapon_Lists.Vector;
    Current_Weapon    : Positive;
    ...
end record;

but it sounds as if you think those fields should be named Vector and Positive.

-- 
Jeff Carter
"Brave Sir Robin ran away."
Monty Python and the Holy Grail
59

Re: Type naming conventions: Any_Foo

[Dmitry A. Kazakov]

On 2019-12-06 21:11, Jeffrey R. Carter wrote:
> On 12/5/19 10:33 PM, Niklas Holsti wrote:
>>
>> But if a value of the type Weapon_Id is an identifier of a Weapon, how 
>> can you defend saying
>>
>>     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.

Which something is the variable Weapon in the example above. Though 
Holstered_Weapon, Current_Weapon might be better. But then again, 
"_Weapon" would look like a nasty suffix.

I don't think there is a universal solution and I agree with Randy that 
a consistent convention is better than anything else (unless pushed ad 
absurdum like Hungarian notation).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Type naming conventions: Any_Foo

[Niklas Holsti]

On 2019-12-06 22:11, Jeffrey R. Carter wrote:
> On 12/5/19 10:33 PM, Niklas Holsti wrote:
>>
>> But if a value of the type Weapon_Id is an identifier of a Weapon, how 
>> can you defend saying
>>
>>     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.

> I would probably write something like
> 
> type Character_Info is record
>     ...
>     Available_Weapons : Weapon_Lists.Vector;
>     Current_Weapon    : Positive;
>     ...
> end record;
> 
> but it sounds as if you think those fields should be named Vector and 
> Positive.

No, no, when a variable or component has a specific role, such as being 
the "current weapon", this role should be reflected in the chosen 
identifier, here Available_Weapons and Current_Weapon. The problem with 
having to distinguish variable/component names from type names arises 
only for variables/components that do not have such specific roles. For 
example:

   function Is_Lethal (Weapon : Weapon_T) return Boolean;

The ARM often uses "Item" for such subprogram parameters, but that fails 
when there is more than one (or if the type is called "Item"...).

Unfortunately, such non-specific cases are not rare, and new ones come 
up during SW development and evolution, so it feels safer to prepare for 
them by avoiding such identifier conflicts, for example by the "_T(ype)" 
suffix on type names.

Some people have suggested decorating the variable/component name 
instead of the type name, for example

    function Is_Lethal (The_Weapon : Weapon) return Boolean

but (as you say) such prefixes are worse than suffixes.

I have also seen coding rules that require specific suffixes on formal 
parameters, such as:

    function Is_Lethal (Weapon_P : Weapon) return Boolean;

but they tend to also require suffixes (like "_T") on type names, so 
there were are again.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Type naming conventions: Any_Foo

[Jeffrey R. Carter]

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. In other 
words, Weapon contains a Weapon identifier, and the declaration is not 
misleading at all.

-- 
Jeff Carter
"C++ is like jamming a helicopter inside a Miata
and expecting some sort of improvement."
Drew Olbrich
51

Re: Type naming conventions: Any_Foo

[Niklas Holsti]

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.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Type naming conventions: Any_Foo

[Jeffrey R. Carter]

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

Re: Type naming conventions: Any_Foo

[AdaMagica]

Am Donnerstag, 5. Dezember 2019 11:51:36 UTC+1 schrieb AdaMagica:
> procedure Attack (Using: Weapon);
> Attack (Using => Catapult);

As nice as this may read in user's code, within the body of Attack, the parameter name is not optimal.

Also a declaration like

  My_Weapon: Weapons.Weapon;

is akward when use-clause is banned. So a further point to consider is whether you want your package to be used with use-clause or without:

  My_Weapon: Weapons.Object;

I'm not sure I like this.

Re: Type naming conventions: Any_Foo

[J-P. Rosen]

Le 06/12/2019 à 09:57, AdaMagica a écrit :
> Also a declaration like
> 
> My_Weapon: Weapons.Weapon;
> 
> is akward when use-clause is banned. So a further point to consider
> is whether you want your package to be used with use-clause or
> without:
> 
> My_Weapon: Weapons.Object;
> 
> I'm not sure I like this.

Small remark: do not confuse using the use clause, and not using
selected names. You are perfectly allowed to use slected names within
the scope of a use clause if you feel it is more readable!

I am a known supporter of the use clause, however for classes, I use the
package for the object name, and "object" for the record that's the data
part of it. Of course, I always use selected names in that case.

[small plug] There is an AdaControl rule to check that some names always
use selected notation.

Whether or not you are hostile to the use clause, the best advice is to
choose a name which is nice for your favorite notation, and acceptable
for the other one.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Type naming conventions: Any_Foo

[Optikos]

On Thursday, December 5, 2019 at 4:51:36 AM UTC-6, AdaMagica wrote:
> Of all of these schemes, my favorite is
> Package Foos

In this or any other naming convention that utilizes plural, the convention must eventually inform what to do (in English) with nouns that
a) are the same in both plural & singular (e.g., fish, deer); and
b) have no plural, such as noncount/mass-count nouns (e.g., furniture, software); and
c) the plural (if it exists) most likely refers to the type-of not the (microscopic) instance-of due to using measure words for referring to the (microscopic) instances of (e.g., flour [as dust] versus flours as type of flour; [grain of] sand versus sands as type of sand; [kernel of] rice/corn versus rices as types of rice/corn]); and
d) the plethora of measure words, especially for demarcating plural of individuals or of groups (e.g., lions as multiple individuals versus pride of lions as a cohesive group versus prides of lions as multiple of multiple); and
e) nonconforming foreign-import plurals (e.g., courts marshal; attorneys general); and
f) acronyms & initialisms, especially when the pluralized noun in the acronym or initialism is not the final word (e.g., should certificates of deposit be CDs and attorneys general be AGs since it is not certificate of deposits and attorney generals?); and
g) Latin-derived plurals versus English-derived plurals (e.g., radii versus radiuses both being perfectly correct & widely accepted in English).

(Of which f is the most pedantic in a case-insensitive language such as Ada, because usually the nonagreement is DVDs versus Dvds and CDs versus Cds, not CsD, and AGs versus Ags, not AsG.)

Given all that opportunity for debate, there is some wisdom in rejecting English plurals per se to instead:
A) always add -s when the singular phonetically ends in not-s and always add -es when the singular phonetically ends in -s, as in mouse->mouses, ax->axes, axis->axises.
or
B) always use the same affix as prefix or suffix, as in Pkg_Foo or Foo_Pkg.

Option B makes scripting automation especially easy in the build environment or in source-code generation or refactoring, so that the scripting need not have AI-esque knowledge of English (or an artificial-artificial intelligence of a giant human-curated look-up table).

Re: Type naming conventions: Any_Foo

[Shark8]

In a move that will please no-one, I present the qualified package-name convention:

Package Example is
  Type Weapon is null record;
  Procedure Operation( Weapon : Example.Weapon ) is null;
End Example;