From dsmith@clark.net Mon Feb 24 15:00:15 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA29422; Mon, 24 Feb 1997 15:00:15 -0500 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by ida.org (4.1/SMI-4.1) id AA29508; Mon, 24 Feb 97 15:00:33 EST Received: from wormhole.mtc.iitri.com by sw-eng.falls-church.va.us (8.7.1/) id TAA10897; Mon, 24 Feb 1997 19:54:00 GMT Received: from mail.clark.net by mtc.iitri.com (4.1/3.1.090690-IITRI-MTC) id AA02367; Mon, 24 Feb 97 14:58:11 EST Received: from clark.net (root@explorer.clark.net [168.143.0.7]) by mail.clark.net (8.8.5/8.6.5) with ESMTP id OAA01952; Mon, 24 Feb 1997 14:50:18 -0500 (EST) Received: from [168.143.24.1] (dsmith.clark.net [168.143.24.1]) by clark.net (8.8.5/8.7.1) with ESMTP id OAA24228; Mon, 24 Feb 1997 14:50:31 -0500 (EST) Date: Mon, 24 Feb 1997 14:50:31 -0500 (EST) X-Sender: dsmith@clark.net (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ASIS-comment@sw-eng.falls-church.va.us From: Doug Smith Subject: General Comments Cc: jbitto@gsg.eds.com Content-Length: 3624 Status: OR !topic Formal Parameter Naming Conventions !reference ASIS 95-ss.ss(pp) !from Doug Smith 97-02-22 !keywords formal parameter naming convention !discussion References to "ASIS." are unnecessary in child packages. It appears to be necessary in many cases because of the unfortunate convention of using the type name for the formal parameter, as in: package Asis.Compilation_Units is function Unit_Kind (Compilation_Unit : in Asis.Compilation_Unit) return Asis.Unit_Kinds; Formal parameter names should be specific, while the type is general. In this example, a more appropriate name for the formal parameter would be "Unit" or "of_Unit". Possibly the function would more appropriately be called "Kind_of" or "Kind". Unless there is compelling rationale that this convention will not lead to implementation problems, an alternative should be adopted and a guideline imposed that formal parameters not be named the same as the type's simple name. From colket@smtp-gw.spawar.navy.mil Thu Apr 24 15:24:25 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA23814; Thu, 24 Apr 1997 15:24:25 -0400 Received: from opal.spawar.navy.mil by ida.org (4.1/SMI-4.1) id AA22196; Thu, 24 Apr 97 15:24:54 EDT Received: from smtp-gw.spawar.navy.mil by opal.spawar.navy.mil (5.x/SMI-SVR4) id AA27370; Thu, 24 Apr 1997 15:15:05 -0400 Received: from ccMail by smtp-gw.spawar.navy.mil (IMA Internet Exchange 1.04b) id 35fade30; Thu, 24 Apr 97 15:00:51 -0400 Mime-Version: 1.0 Date: Thu, 24 Apr 1997 15:05:58 -0400 Message-Id: <35fade30@smtp-gw.spawar.navy.mil> From: colket@smtp-gw.spawar.navy.mil (Currie Colket) Subject: ***IMPORTANT*** Please Reconsider Technical Issue #042 To: "ASISWG/ASISRG Officers" , colket@smtp-gw.spawar.navy.mil (Currie Colket), "Doug Smith" Cc: "ASIS Technical" , "Clyde Roby" , "Sergey Rybin" , "Steve Blake" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Length: 3815 Status: OR Dear ASIS Officers, The resolution of all Editorial Comments and Technical Comments appears to be quite satisfactory. The only resolution of concern is that for I#042 titled: "Formal Parameter Naming Conventions." Although the issue is made in the context of I#043, which was rejected, there is still value to have the defining_identifier use a name that is different from its type. For example, in the following function specification: function Unit_Kind (Compilation_Unit : in Asis.Compilation_Unit) return Asis.Unit_Kinds; The defining_identifier Compilation_Unit could be changed to The_Compilation_Unit. I have talked with Doug Smith, the originator of I#043, and we both now believe we should reconsider this aspect of the issue. This change could have an important impact on tool builders by making the interface easier to read and understand. He strongly feels that this change will be of significant benefit to ASIS tool builders. Most of the changes would be things such as: Names => The_Names Element => The_Element Declaration => The_Declaration Defining_Name => The_Defining_Name Definition => The_Definition Expression => The_Expression Path => The_Path Clause => The_Clause These changes should be easy to perform using a search & replace operation on a word processor. This would also eliminate some inconsistencies we currently have in the specification such as the use of "Element" in some cases and "The_Element" in other places. The strongest argument for the resolution is that the 3 implementors present at the March 1997 ASISWG/ASISRG meeting already have implementations of which this would impact. ASIS-Officers and others, please comment. In particular it would be valuable to hear from each implementor by Friday, tomorrow morning, if such a change would create any serious impact to your implementation. If there is indeed a serious impact, this would be good to know. Please comment for or against! v/r Currie Colket Chair ASISWG/ASISRG Issue #042 with draft resolution attached => +-----------------------------------------------------------------------+ !ASIS Issue #042 !topic Formal parameter naming conventions !reference ASIS 95 !from Doug Smith 97-02-24 !keywords formal parameter naming convention !discussion References to "ASIS." are unnecessary in child packages. It appears to be necessary in many cases because of the unfortunate convention of using the type name for the formal parameter, as in: package Asis.Compilation_Units is function Unit_Kind (Compilation_Unit : in Asis.Compilation_Unit) return Asis.Unit_Kinds; Formal parameter names should be specific, while the type is general. In this example, a more appropriate name for the formal parameter would be "Unit" or "of_Unit". Possibly the function would more appropriately be called "Kind_of" or "Kind". Unless there is compelling rationale that this convention will not lead to implementation problems, an alternative should be adopted and a guideline imposed that formal parameters not be named the same as the type's simple name. !resolution Rejected. !date 97-03-26 !Notes Three ASIS implementors viewed the current convention of specifying formal parameters as being preferred for readability purposes. This convention was chosen for simplicity and uniformity more than anything else. There are no implementation problems caused by this choice. ASIS employs specific names for formal parameters wherever the nature of the input is specific. When the formal parameter can be general, the name used matches the type name. From sblake@alsys.com Thu Apr 24 17:01:56 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id RAA24791; Thu, 24 Apr 1997 17:01:56 -0400 Received: from gw.alsys.com by ida.org (4.1/SMI-4.1) id AA24340; Thu, 24 Apr 97 17:02:25 EDT Received: from rasht.alsys.com (mailhub.alsys.com) by gw.alsys.com (4.1/SMI-4.1.1) id AA00315; Thu, 24 Apr 97 14:01:43 PDT Received: from puumba.telesoft by rasht.alsys.com (4.1/TS-1.2c) id AA10176; Thu, 24 Apr 97 14:00:25 PDT Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id OAA21237; Thu, 24 Apr 1997 14:00:23 -0700 Date: Thu, 24 Apr 1997 14:00:23 -0700 From: sblake@alsys.com (Steve Blake @pulsar) Message-Id: <199704242100.OAA21237@puumba.telesoft> To: asis-officers@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dsmith@clark.net Subject: Re: ***IMPORTANT*** Please Reconsider Technical Issue #042 Cc: asis-technical@sw-eng.falls-church.va.us, roby@ida.org, rybin@alex.srcc.msu.su, sblake@thomsoft.com Content-Length: 3002 Status: OR I feel that this issue should remain rejected. >The only resolution of concern is that for I#042 titled: "Formal >Parameter Naming Conventions." Although the issue is made in the >context of I#043, which was rejected, there is still value to have the >defining_identifier use a name that is different from its type. For >example, in the following function specification: > > function Unit_Kind (Compilation_Unit : in Asis.Compilation_Unit) > return Asis.Unit_Kinds; > >The defining_identifier Compilation_Unit could be changed to >The_Compilation_Unit. I have talked with Doug Smith, the originator of >I#043, and we both now believe we should reconsider this aspect of the >issue. > >This change could have an important impact on tool builders by making >the interface easier to read and understand. He strongly feels that >this change will be of significant benefit to ASIS tool builders. I don't see how changing Compilation_Unit to The_Compilation_Unit makes such an impact. How does it make it easier to read? Please show me an example that will convince me of the benefit. >Most of the changes would be things such as: > > Names => The_Names > Element => The_Element > Declaration => The_Declaration > Defining_Name => The_Defining_Name > Definition => The_Definition > Expression => The_Expression > Path => The_Path > Clause => The_Clause > >These changes should be easy to perform using a search & replace >operation on a word processor. This would also eliminate some >inconsistencies we currently have in the specification such as the use >of "Element" in some cases and "The_Element" in other places. There are other potential impacts to consider: If this change is made, then there would no longer be any reason to name the type Asis.Compilation_Unit. Would we then change these occurrances as well? Who will then go through the commentary and make sure that occurrances of Compilation_Unit or compilation_unit still refer to the object rather than the type? Will someone read the commentary and make sure wording like "which Compilation_Unit" does not become garbage like "which The_Compilation_Unit"? Let's not make a last minute fix to something that is not broken in the first place. >The strongest argument for the resolution is that the 3 implementors >present at the March 1997 ASISWG/ASISRG meeting already have >implementations of which this would impact. I have no case to claim this would be a serious impact on our implementation. >ASIS-Officers and others, please comment. In particular it would be >valuable to hear from each implementor by Friday, tomorrow morning, if >such a change would create any serious impact to your implementation. >If there is indeed a serious impact, this would be good to know. >Please comment for or against! Against! Steve Blake From dsmith@clark.net Thu Apr 24 19:15:39 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id TAA24924; Thu, 24 Apr 1997 19:15:39 -0400 Received: from mail.clark.net by ida.org (4.1/SMI-4.1) id AA26258; Thu, 24 Apr 97 19:15:39 EDT Received: from clark.net (root@explorer.clark.net [168.143.0.7]) by mail.clark.net (8.8.5/8.6.5) with ESMTP id TAA03947; Thu, 24 Apr 1997 19:11:51 -0400 (EDT) Received: from [168.143.24.1] (dsmith.clark.net [168.143.24.1]) by clark.net (8.8.5/8.7.1) with ESMTP id TAA28248; Thu, 24 Apr 1997 19:12:06 -0400 (EDT) Message-Id: In-Reply-To: <199704242100.OAA21237@puumba.telesoft> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Apr 1997 19:16:12 -0400 To: sblake@alsys.com (Steve Blake @pulsar), asis-officers@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil From: Doug Smith Subject: Re: ***IMPORTANT*** Please Reconsider Technical Issue #042 Cc: asis-technical@sw-eng.falls-church.va.us, roby@ida.org, rybin@alex.srcc.msu.su, sblake@thomsoft.com Content-Length: 3781 Status: OR At 5:00 PM -0400 4/24/97, Steve Blake @pulsar wrote: >I feel that this issue should remain rejected. > [snip] >> function Unit_Kind (Compilation_Unit : in Asis.Compilation_Unit) >> return Asis.Unit_Kinds; [snip] > >I don't see how changing Compilation_Unit to The_Compilation_Unit makes such >an impact. How does it make it easier to read? Please show me an example that >will convince me of the benefit. > > >>Most of the changes would be things such as: >> >> Names => The_Names >> Element => The_Element [snip] I would have gone with something like: function Unit_Kind (Unit : in Compilation_Unit) return Unit_Kinds; And there are many other naming conventions I would change. However, this issue is more significant in concert with another change I recommended which was rejected: Moving type declarations (such as Compilation_Unit) to the child packages. I understand the historical and other issues which prevent stronger encapsulation. However, this naming convention's success is tied to the current practice of keeping the type declarations in a separate package! Also you cannot consistently apply the naming convention unless you consistently apply the convention of putting type declarations in a package which does not use that type as a formal paramter. Excuse me, but who supports this in the first place? >There are other potential impacts to consider: > >If this change is made, then there would no longer be any reason to name the >type Asis.Compilation_Unit. Would we then change these occurrances as well? Why not, I don't see any significant benefit for keeping the full path name. Enlighten me... >Who will then go through the commentary and make sure that occurrances of >Compilation_Unit or compilation_unit still refer to the object rather than >the type? Will someone read the commentary and make sure wording like >"which Compilation_Unit" does not become garbage like >"which The_Compilation_Unit"? A good argument for the convention of using "Which_" instead of "The_" (i.e. Which_Compilation_Unit). I'm not arguing for this, just noting one way to deal with garbage. I'm also assuming that the confusion about object/type is talking about the documentation and not the Ada specifications. In fact, how can you tell in the documentation whether "Compilation_Unit" refers to the parameter or the type? Who has gone through the documentaton and made sure this ambiguity does not cause confusion? >Let's not make a last minute fix to something that is not broken in the >first place. Yes, better is the enemy of good enough. Others are in a better ;^) position to judge this than I. However, we don't agree on what "broken" means. >>The strongest argument for the resolution is that the 3 implementors >>present at the March 1997 ASISWG/ASISRG meeting already have >>implementations of which this would impact. > >I have no case to claim this would be a serious impact on our >implementation. And that's one of the reasons I pushed a little harder on this one. The change to a more conventional naming convention doesn't seem to be a difficult one. However, a counter example showing a significant impact would change my mind. As far as I can tell, the Ada compiler will help change all of the existing implementations and applications within one build. [snip] > >Steve Blake Here's a long term argument which probably has less weight with most people. The current naming convention encourages type declarations remain in separate packages. Again, others are in a better position to judge the likelihood that a future ASIS update might consider moving the type declarations and leave that decision to them. Doug From sblake@alsys.com Thu Apr 24 20:33:31 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id UAA24968; Thu, 24 Apr 1997 20:33:30 -0400 Received: from gw.alsys.com by ida.org (4.1/SMI-4.1) id AA26921; Thu, 24 Apr 97 20:34:01 EDT Received: from rasht.alsys.com (mailhub.alsys.com) by gw.alsys.com (4.1/SMI-4.1.1) id AA05723; Thu, 24 Apr 97 17:32:45 PDT Received: from puumba.telesoft by rasht.alsys.com (4.1/TS-1.2c) id AA15304; Thu, 24 Apr 97 17:31:27 PDT Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id RAA25120; Thu, 24 Apr 1997 17:31:26 -0700 Date: Thu, 24 Apr 1997 17:31:26 -0700 From: sblake@alsys.com (Steve Blake @pulsar) Message-Id: <199704250031.RAA25120@puumba.telesoft> To: asis-officers@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dsmith@clark.net, sblake@alsys.com Subject: Re: ***IMPORTANT*** Please Reconsider Technical Issue #042 Cc: asis-technical@sw-eng.falls-church.va.us, roby@ida.org, rybin@alex.srcc.msu.su, sblake@thomsoft.com Content-Length: 5510 Status: OR >From dsmith@clark.net Thu Apr 24 16:15:06 1997 > >At 5:00 PM -0400 4/24/97, Steve Blake @pulsar wrote: >>I feel that this issue should remain rejected. >> >[snip] >>> function Unit_Kind (Compilation_Unit : in Asis.Compilation_Unit) >>> return Asis.Unit_Kinds; >[snip] >> >>I don't see how changing Compilation_Unit to The_Compilation_Unit makes such >>an impact. How does it make it easier to read? Please show me an example that >>will convince me of the benefit. >> >> >>>Most of the changes would be things such as: >>> >>> Names => The_Names >>> Element => The_Element >[snip] >I would have gone with something like: > function Unit_Kind (Unit : in Compilation_Unit) > return Unit_Kinds; This was considered long ago, and it was felt that Unit conflicted with the term program_unit which is not necessarily a compilation unit. I know, Unit_Kind itself would be Compilation_Unit_Kind if we were absolutely consistent everywhere. >And there are many other naming conventions I would change. However, this >issue is more significant in concert with another change I recommended >which was rejected: Moving type declarations (such as Compilation_Unit) >to the child packages. I understand the historical and other issues which >prevent stronger encapsulation. However, this naming convention's success >is tied to the current practice of keeping the type declarations in a >separate package! > >Also you cannot consistently apply the naming convention unless you >consistently apply the convention of putting type declarations in a package >which does not use that type as a formal paramter. Excuse me, but who >supports this in the first place? I don't think the current convention prohibits moving the type declarations to children. This example is legal: package ASIS is end; package ASIS.Test is type Compilation_Unit is new Integer; procedure Unit_Test (Compilation_Unit : in Asis.Test.Compilation_Unit); end; > >>There are other potential impacts to consider: >> >>If this change is made, then there would no longer be any reason to name the >>type Asis.Compilation_Unit. Would we then change these occurrances as well? > >Why not, I don't see any significant benefit for keeping the full path >name. Enlighten me... That is what I'm saying, that if this initial change is made, then more changes follow, and then maybe more after that. I'm urging us to think this through before jumping in head first. > >>Who will then go through the commentary and make sure that occurrances of >>Compilation_Unit or compilation_unit still refer to the object rather than >>the type? Will someone read the commentary and make sure wording like >>"which Compilation_Unit" does not become garbage like >>"which The_Compilation_Unit"? > >A good argument for the convention of using "Which_" instead of >"The_" (i.e. Which_Compilation_Unit). I'm not arguing for this, just >noting one way to deal with garbage. I'm also assuming that >the confusion about object/type is talking about the documentation and >not the Ada specifications. In fact, how can you tell in the documentation >whether "Compilation_Unit" refers to the parameter or the type? Who has >gone through the documentaton and made sure this ambiguity does not cause >confusion? > >>Let's not make a last minute fix to something that is not broken in the >>first place. > >Yes, better is the enemy of good enough. Others are in a better ;^) >position to judge this than I. However, we don't agree on what "broken" >means. I believe we have made every attempt to make the commentary and other documentation clear about this. I hope you would understand that after the effort of many people for many years providing feedback and corrections, that I'm not ecstatic about making a potentially disruptive change that could screw up 15,000 lines of documentation, at the eleventh hour, after the final ASISRG meeting, unless there is a pretty darn compelling reason to do so. Respectfully speaking, what makes this better? Aren't we really just talking about personal preferences here? I'm not yet convinced that there is either a fatal flaw or a superior benefit that justifies this change. > >>>The strongest argument for the resolution is that the 3 implementors >>>present at the March 1997 ASISWG/ASISRG meeting already have >>>implementations of which this would impact. >> >>I have no case to claim this would be a serious impact on our >>implementation. > >And that's one of the reasons I pushed a little harder on this one. The >change to a more conventional naming convention doesn't seem to be a >difficult one. However, a counter example showing a significant impact >would change my mind. As far as I can tell, the Ada compiler will help >change all of the existing implementations and applications within one >build. I'm already in agreement with you here. However, my point is that the real impact is on the specification and documentation. > >[snip] >> >>Steve Blake > >Here's a long term argument which probably has less weight with most >people. The current naming convention encourages type declarations >remain in separate packages. Again, others are in a better position >to judge the likelihood that a future ASIS update might consider >moving the type declarations and leave that decision to them. The example above shows this should not be a concern. Steve Blake > >Doug > From dsmith@clark.net Thu Apr 24 21:23:22 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id VAA25013; Thu, 24 Apr 1997 21:23:21 -0400 Received: from mail.clark.net by ida.org (4.1/SMI-4.1) id AA27501; Thu, 24 Apr 97 21:23:44 EDT Received: from clark.net (root@explorer.clark.net [168.143.0.7]) by mail.clark.net (8.8.5/8.6.5) with ESMTP id VAA13641; Thu, 24 Apr 1997 21:20:22 -0400 (EDT) Received: from [168.143.24.1] (dsmith.clark.net [168.143.24.1]) by clark.net (8.8.5/8.7.1) with ESMTP id VAA17978; Thu, 24 Apr 1997 21:20:37 -0400 (EDT) Message-Id: In-Reply-To: <199704250031.RAA25120@puumba.telesoft> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Apr 1997 21:24:44 -0400 To: sblake@alsys.com (Steve Blake @pulsar), asis-officers@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil From: Doug Smith Subject: Re: ***IMPORTANT*** Please Reconsider Technical Issue #042 Cc: asis-technical@sw-eng.falls-church.va.us, roby@ida.org, rybin@alex.srcc.msu.su, sblake@thomsoft.com Content-Length: 2742 Status: OR At 8:31 PM -0400 4/24/97, Steve Blake @pulsar wrote: >>From dsmith@clark.net Thu Apr 24 16:15:06 1997 [snip] >>I would have gone with something like: >> function Unit_Kind (Unit : in Compilation_Unit) >> return Unit_Kinds; > >This was considered long ago, and it was felt that Unit conflicted with the >term program_unit which is not necessarily a compilation unit. I know, >Unit_Kind itself would be Compilation_Unit_Kind if we were absolutely >consistent everywhere. I was addressing Currie's suggestion which you dismissed as a documentation problem (i.e. creates garbage [not natural to read?]) It's not germain to the point, unless you are saying that there is no appropriate name for the formal parameter other than Compilation_Unit. [snip] >I don't think the current convention prohibits moving the type declarations >to children. This example is legal: > >package ASIS is >end; > >package ASIS.Test is > type Compilation_Unit is new Integer; > procedure Unit_Test (Compilation_Unit : in Asis.Test.Compilation_Unit); >end; You are correct. I had not considered continuing the full path name for the type..an obvious solution. Unfortunately, I cannot speak from experience about how well this works in practice, so I can't object. >>>There are other potential impacts to consider: >>> >>>If this change is made, then there would no longer be any reason to name the >>>type Asis.Compilation_Unit. Would we then change these occurrances as well? >> >>Why not, I don't see any significant benefit for keeping the full path >>name. Enlighten me... > >That is what I'm saying, that if this initial change is made, then more >changes follow, and then maybe more after that. I'm urging us to think this >through before jumping in head first. Agreed. [snip] >Respectfully speaking, what makes this better? Aren't we really just >talking about personal preferences here? I'm not yet convinced that there >is either a fatal flaw or a superior benefit that justifies this change. You've made a good argument that we are not boxed in with this naming convention. If it is possible to move the type declarations without introducing implementation problems, then I will accept the formal naming convention as it is. I'll leave implementors or those more experienced to verify that is the case. [snip] > >Steve Blake As with any consensus building, we are looking for something we can all live with (not necessarily what we all think is the best). My major concern is the placement of type declarations and Steve has allowed for future improvements. I can live with the naming convention as it stands if Steve's proposed solution for moving the type declarations is valid. Doug From rybin@possum.srcc.msu.su Fri Apr 25 03:29:49 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id DAA25254; Fri, 25 Apr 1997 03:29:48 -0400 Received: from crocus.gamma.ru by ida.org (4.1/SMI-4.1) id AA29832; Fri, 25 Apr 97 03:25:01 EDT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id LAA18769; Fri, 25 Apr 1997 11:23:14 +0400 (MSD) Received: by gamma.srcc.msu.su; Fri, 25 Apr 1997 11:22:32 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Fri, 25 Apr 1997 11:03:49 +0400 To: asis-officers@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dsmith@clark.net, sblake@alsys.com Cc: asis-technical@sw-eng.falls-church.va.us, roby@ida.org, sblake@thomsoft.com References: <199704250031.RAA25120@puumba.telesoft> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Fri, 25 Apr 97 11:03:48 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: ***IMPORTANT*** Please Reconsider Technical Issue #042 Lines: 19 Content-Length: 912 Status: OR I agree with Steve's position in this discussion. From implementer's viewpoint, changing the names of the formal parametrs would be a pain, but only for a day of work at most (multi-file search-and-replace plus striggling with compilation errors plus the full regress testing). But, for sure, better is an enemy of good enough. Any change like this requires a new careful analyziz of all the documentation (15_000 lines!). I am really afraid if this last-minute change. There is still a lot of things in the ASIS definition needing improvings (and even fixes!), but, definitely, now ASIS is in far better shape then it was before. I think, this change will change nothing in the ASIS standardization process and perspective. No none information technology standard is perfect, but some of them are useful. I think, the problem being discussed does not make any barries for ASIS to be useful :) Sergey Rybin. From alfred.strohmeier@di.epfl.ch Fri Apr 25 04:09:38 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id EAA25282; Fri, 25 Apr 1997 04:09:37 -0400 Received: from dimail.epfl.ch by ida.org (4.1/SMI-4.1) id AA29959; Fri, 25 Apr 97 04:09:51 EDT Received: from lglsun11.epfl.ch by dimail.epfl.ch (SMI-8.6/EPFL-DI-5.2-S-MX) id JAA15541; Fri, 25 Apr 1997 09:54:33 +0200 Received: from lglsun12 by lglsun11.epfl.ch (SMI-8.6/EPFL-DI-5.2-MX) id JAA07704; Fri, 25 Apr 1997 09:53:42 +0200 Sender: astroh@di.epfl.ch Message-Id: <33606350.5752@di.epfl.ch> Date: Fri, 25 Apr 1997 09:54:56 +0200 From: Alfred Strohmeier Organization: EPFL-DI-LGL X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u) Mime-Version: 1.0 To: Currie Colket Cc: ASISWG/ASISRG Officers , Doug Smith , ASIS Technical , Clyde Roby , Sergey Rybin , Steve Blake Subject: Re: ***IMPORTANT*** Please Reconsider Technical Issue #042 References: <35fade30@smtp-gw.spawar.navy.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 4474 Status: OR I'm strongly against last minute changes. Moreover, discussions about naming conventions last for ever: everybody has his own opinion, with some very nice arguments, but at the very end, you have to decide. And there is NO best solution. -- Alfred Currie Colket wrote: > > Dear ASIS Officers, > > The resolution of all Editorial Comments and Technical Comments > appears to be quite satisfactory. > > The only resolution of concern is that for I#042 titled: "Formal > Parameter Naming Conventions." Although the issue is made in the > context of I#043, which was rejected, there is still value to have the > defining_identifier use a name that is different from its type. For > example, in the following function specification: > > function Unit_Kind (Compilation_Unit : in Asis.Compilation_Unit) > return Asis.Unit_Kinds; > > The defining_identifier Compilation_Unit could be changed to > The_Compilation_Unit. I have talked with Doug Smith, the originator of > I#043, and we both now believe we should reconsider this aspect of the > issue. > > This change could have an important impact on tool builders by making > the interface easier to read and understand. He strongly feels that > this change will be of significant benefit to ASIS tool builders. > > Most of the changes would be things such as: > > Names => The_Names > Element => The_Element > Declaration => The_Declaration > Defining_Name => The_Defining_Name > Definition => The_Definition > Expression => The_Expression > Path => The_Path > Clause => The_Clause > > These changes should be easy to perform using a search & replace > operation on a word processor. This would also eliminate some > inconsistencies we currently have in the specification such as the use > of "Element" in some cases and "The_Element" in other places. > > The strongest argument for the resolution is that the 3 implementors > present at the March 1997 ASISWG/ASISRG meeting already have > implementations of which this would impact. > > ASIS-Officers and others, please comment. In particular it would be > valuable to hear from each implementor by Friday, tomorrow morning, if > such a change would create any serious impact to your implementation. > If there is indeed a serious impact, this would be good to know. > > Please comment for or against! > > v/r > Currie Colket > Chair ASISWG/ASISRG > > Issue #042 with draft resolution attached => > +-----------------------------------------------------------------------+ > !ASIS Issue #042 > !topic Formal parameter naming conventions > !reference ASIS 95 > !from Doug Smith 97-02-24 > !keywords formal parameter naming convention > !discussion > > References to "ASIS." are unnecessary in child packages. It appears > to be necessary in many cases because of the unfortunate convention > of using the type name for the formal parameter, as in: > > package Asis.Compilation_Units is > function Unit_Kind (Compilation_Unit : in Asis.Compilation_Unit) > return Asis.Unit_Kinds; > > Formal parameter names should be specific, while the type is general. > In this example, a more appropriate name for the formal parameter > would be "Unit" or "of_Unit". Possibly the function would more > appropriately be called "Kind_of" or "Kind". > > Unless there is compelling rationale that this convention will not > lead to implementation problems, an alternative should be adopted > and a guideline imposed that formal parameters not be named the same > as the type's simple name. > > !resolution Rejected. > !date 97-03-26 > !Notes > > Three ASIS implementors viewed the current convention of specifying > formal parameters as being preferred for readability purposes. > > This convention was chosen for simplicity and uniformity more than > anything else. There are no implementation problems caused by this > choice. > > ASIS employs specific names for formal parameters wherever the nature > of the input is specific. When the formal parameter can be general, > the name used matches the type name. -- Prof. Alfred Strohmeier, Swiss Fed Inst of Technology in Lausanne EPFL-DI-LGL, CH-1015 Lausanne, Switzerland Tel +41 21 693 4231, Fax +41 21 693 5079 mailto:alfred.strohmeier@di.epfl.ch or http://lglwww.epfl.ch/ From dhe@cyberport.net Fri Apr 25 08:02:10 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id IAA25386; Fri, 25 Apr 1997 08:02:10 -0400 Received: from cpmt2.cyberport.net (ns2.cyberport.net) by ida.org (4.1/SMI-4.1) id AA01126; Fri, 25 Apr 97 07:57:16 EDT Received: from cyb-pm1-017.cyberport.net (cyb-pm1-017.cyberport.net [208.136.100.82]) by cpmt2.cyberport.net (8.6.9/8.6.9) with SMTP id FAA26271; Fri, 25 Apr 1997 05:57:05 -0600 Message-Id: Date: Fri, 25 Apr 97 04:57:46 +0100 From: "Daniel Ehrenfried" Subject: Re: ***IMPORTANT*** Please Reconsider Technical Issue #042 Reply-To: dhe@cyberport.net To: "Currie Colket" , "ASISWG/ASISRG Officers" , "Doug Smith" Cc: "ASIS Technical" , "Clyde Roby" , "Sergey Rybin" , "Steve Blake" X-Mailer: VersaTerm Link v1.1.5 Content-Length: 1284 Status: OR >Dear ASIS Officers, > >The resolution of all Editorial Comments and Technical Comments >appears to be quite satisfactory. > >The only resolution of concern is that for I#042 titled: "Formal >Parameter Naming Conventions." Although the issue is made in the >context of I#043, which was rejected, there is still value to have the >defining_identifier use a name that is different from its type. For >example, in the following function specification: > > function Unit_Kind (Compilation_Unit : in Asis.Compilation_Unit) > return Asis.Unit_Kinds; > >The defining_identifier Compilation_Unit could be changed to >The_Compilation_Unit. I have talked with Doug Smith, the originator of >I#043, and we both now believe we should reconsider this aspect of the >issue. > >This change could have an important impact on tool builders by making >the interface easier to read and understand. He strongly feels that >this change will be of significant benefit to ASIS tool builders. > >>Please comment for or against! I am a big consumer of Asis interfaces and I must disagree with this suggestion. I do not believe that this change will be a significant benefit > >v/r >Currie Colket >Chair ASISWG/ASISRG > Dan Ehrenfried (406) 854-2160 (406) 854-2170 (fax) From colket@smtp-gw.spawar.navy.mil Fri Apr 25 08:46:22 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id IAA25453; Fri, 25 Apr 1997 08:46:21 -0400 Received: from opal.spawar.navy.mil by ida.org (4.1/SMI-4.1) id AA01936; Fri, 25 Apr 97 08:46:55 EDT Received: from smtp-gw.spawar.navy.mil by opal.spawar.navy.mil (5.x/SMI-SVR4) id AA09652; Fri, 25 Apr 1997 08:37:00 -0400 Received: from ccMail by smtp-gw.spawar.navy.mil (IMA Internet Exchange 1.04b) id 360a37a0; Fri, 25 Apr 97 08:28:42 -0400 Mime-Version: 1.0 Date: Fri, 25 Apr 1997 08:20:07 -0400 Message-Id: <360a37a0@smtp-gw.spawar.navy.mil> From: colket@smtp-gw.spawar.navy.mil (Currie Colket) Subject: Re: ***IMPORTANT*** Please Reconsider Technical Issue #042 To: asis-officers@sw-eng.falls-church.va.us, dsmith@clark.net, "Daniel Ehrenfried" Cc: asis-technical@sw-eng.falls-church.va.us, roby@ida.org, rybin@alex.srcc.msu.su, sblake@thomsoft.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Length: 236 Status: OR Dear ASIS Officers, The resolution of I#042 titled: "Formal Parameter Naming Conventions." will remain X (Rejected). The additional discussion provides a stronger motivation for the agreed upon resolution. Thank you. v/r Currie