Forum OpenACS Development: ad_parameter deprecated in favor of parameter::get?

then why make parameter::get MORE of a pain to use by making me type "parameter" twice every time?  Looks like someone got on a "everything should be a - argument" trip.  That is silly.  The core api shouldn't be needlessly verbose.  parameter::get foo is plenty clear without -parameter. :(

I will volunteer to do the s/-parameter// globally (for ::set too) if you like.  Otherwise I'm sticking with the "deprecated" ad_parameter like everyone else.  (By a 762:58 margin :0)

Posted by Dave Bauer on

Generally using named parameters makes the code more clear and readable. I think that understanding the code after the fact is more valuable than saving a few keystrokes up front.

I think it makes the code more accessible to someone is isn't intimately familiar with openacs, which is huge and takes quite a while to grasp the entire thing.

Another point is that using all named paramters in a proc is more clear than using a few named paramters and a few positional paramters which some of the original procs do.

Anything that makes it easier to learn openacs is a plus.

Posted by Jonathan Ellis on
I prefer the style of using names for optional parameters.  Certainly in this case, as I already said, adding -parameter to parameter::get foo isn't making things any more clear.  It's not really good tcl style, either...  I'm all in favor of making things easier to learn but pretending we are OpenACS for Dummies is silly because we obviously are not.

As for the "if we use named parameters in one place we should use them everywhere" argument, I'm sure you're familiar with the Emerson quotation about foolish consistency and little minds. :)

In any case I think it's clear developers are voting with their code.

Posted by Dave Bauer on

Well I would appreciate a wider discussion, all previous discussions seemed to favor named paramters.

Most new code is using this style. Two published development guides point to using named parameters: and
although it appears the documentation is silent on this issue.

The developer's tutorial doesn't seem to mention Tcl APIs at all.

Posted by Jonathan Ellis on
I agree that discussion is good.  Let me explain why I feel this way.

C++, python, java, lisp, tcl, ...  There is a reason I can't think of a language that uses named parameters for every function call, and the reason is it's frankly stupid to inflict needless verbosity on everyone in the name of making things simpler for novices.

Anyone from a unix background knows that utilities work the way I describe; you run "find / foo" not "find -path / -expr foo".  If you want optional behavior then you specify -mtime etc.  And if you are a newbie and don't know what the arguments mean then you look up the documentation.  In the case of OpenACS you are going to have to look at the docs anyway because parameter::get isn't meaningful enough to someone who's never seen it before.  And no that doesn't mean we should rename it apm_parameter_from_database::get.

Posted by Tom Jackson on
Hmm, quite interesting. I would think that required arguments would not need to be named. What would be the point of that? Hey, but the OpenACS style is to flip all the tcl conventions around anyway. Required parameters in ad_procs come after the options, unlike tcl. None of this makes anything easier for the novice OpenACSer, although a complete novice might not notice anything funny.
For, um, posterity, I just wanted to note that Tom's statement above that "the OpenACS style is to flip all the tcl conventions around anyway. Required parameters in ad_procs come after the options, unlike tcl." is, AFAIK, completely untrue - there are no standard Tcl conventions when it comes to ordering of optional vs. required parameters, nor named vs. un-named parameters.

This is easily demonstrated by reading the Tcl docs for various Tcl commands. Many, like string, seem to have all the named optional arguments first, all required un-named arguments next, and maybe a few extra un-named optional arguments at the end. Others, like clock format, have a required un-named argument first, with optional named arguments after it.

So I hope these examples from the Tcl core put that particular red herring to rest.

The OpenACS ad_proc standard of "all named -foo parameters first, then all un-named positional parameters next" is at least completely consistent with unix command-line usage parameter ordering (which inspired it), and at least in that one respect, is used consistently throughout OpenACS.

(The whole "parameter::get -parameter $parameter_id" foolishness that started off this thread, and the related question of whether parameters should generally be named or un-named, are of course entirely separate matters. And here and now, I am specifically not addressing those at all.)

Posted by Peter Marklund on
I agree with you that the parameter name argument shouldn't have been named. In general though I've found named parameters to enhance readability, both for Tcl procs (ad_proc) and for Oracle plsql procs and functions. I believe the enhanced readability and maintainability is there not only for novices but also for experienced developers.
Posted by Jerry Asher on
An argument against explicitly naming required arguments is that it can make them appear to be optional.

When I man a function, it helps my 7+-2 brain to be able to skim past the hyphenage to get a quick understanding of a function.

Slightly offtopic, I appreciate the value of using namespace evals, but I dislike what it does to my TAGS table.

namespace eval mypackage {
  proc get {} {}
  proc set {} {}

results in my not being able to find the right get/set function without a great deal of search.  I suspect most people's tcltag uses a combination of find and etags with regexps and a man of etags doesn't make it appear that we can get etags to ignore line breaks.

Using namespaces is probably the right thing to do, but one of these days we may have to break etags and etags.el....  grumble.

Posted by Bart Teeuwisse on


the solution is simple but requires a slightly different coding practice. First define the namespace like so:

namespace eval mypackage {}

Then create the procedures using their fully qualified name as such:

proc mypackage::get {} {}
proc mypackage::set {} {}

This way etags still works.


Posted by Jerry Asher on
Thanks Bart,

I'm not sure that's sufficient though -- unfortunately, we also need to cvs::get all the other packages and developers to follow this pattern.

Yes, by far the predominant practice in the software world, and particularly in tcl, is for mandatory arguments to be un-named.  If you are so worried about making things easier for newbies, write an etags how-to, instead of forcing everyone to type -paramter etc. redundantly.
Posted by Don Baccus on
I have no problem with mandatory parameters not being named.  The name-all-params style was begun by Open Force when they began implementing dotLRN, and at the time no one complained (they raised it in the forums)

How should we decide this?

Don said: "I have no problem with mandatory parameters not being named.  The name-all-params style was begun by Open Force when they began implementing dotLRN, and at the time no one complained (they raised it in the forums)"

I have no problem with that either. But please let's document ALL the params.


isn't an executive decision (after the discussion winds down) the usual way?
Posted by Jun Yamog on

I also raised that issue too when making the doc.  People had the opition to use -parameter.  I made the doc, I also followed the practice.  I see newer code also does that thing, so in my mind I was following a practice/advice properly.

I gave the doc to Joel and maybe he can decide what to do with it.  Anyway maybe the governance should be a good try for this one.

Posted by Jun Yamog on

2 core developers have no problems with it.  But what is the adviced practice?

- named parameters
- no name parameters
- developer's choice

Posted by tammy m on

I'm a newbie. I prefer named parameters. Objective C doesn't do named parameters per se but makes things quite clear by being able to call something like [initWithName:name andType:type] -- as you can see it's clear what is being passed and it's not always necessary to look up the docs. Named parameters offer much the same sort of value. I much prefer named parameters for readability. Frankly, being new to OACS, Tcl + AOLServer (which most new OACS users would likely be as we all know most of these are unfortunately not widely used today), named parameters make Tcl code MUCH easier to read and get at least an idea of what the code is likely meant to do.

Comparing code of a complex software system to Unix command line is just NOT useful. Unix command line is clearly meant to be fast and not used by novices and not to write software systems in. Come on, how many of us CVS and backup our Unix command line work??!!!  Also Unix was written by and for programmers.

OACS does not have this luxury, it's being used by web developers that most of may never have taken a programming class. At lease we hope it's being used, more and more. It's a great platform, let's make it more useable by everybody and not just the diehard core team. Saving a few keystrokes should not be the concern here. PLEASE!

Not to rant but I've had some frustrating times coming up to speed on OACS and I'm a programmer with a BS degree from UCLA who wrote NeXTSTEP programs for about 15 years!!! It should be a lot easier than it is for us newbies:( I think the little things like documenting code and parameters and return values and errors thrown, etc.... ad nauseum really make a difference here.

thanks for listening:)

  • OpenACS is the Unix of the web toolkit world. It is not PHPnuke. It is not WebGUI. It does have a learning curve. It is also by and for programmers.
  • the style of naming only optional parameters is very well-known among programmers. Flouting conventions just for the hell of it does not, as Tom says, make things easier for the novice; it only confuses those with experience in Tcl which is after all one of our target audiences.
  • If you seriously think parameter::get -parameter foo is more clear than parameter::get foo then you are probably the kind of C programmer who uses indexForMyArray in his for loops instead of i. With 15 years of C experiencee you must understand that this is not "saving a few keystrokes;" it's simply bad form, and frankly you can't call yourself proficient in C until you understand this and other idioms.
Naming all parameters is the wrong solution to the wrong problem. If your variable names make sense, 99% of the time it is obvious what you are doing. Writing my_proc -userId $user_id would be pretty silly, but that is what you are advocating. Or db_foreach -name my_query -sql $sql -body {...}. How about util_close_html_tags -htmlFragment $html? Or if the nsd guys subscribed to this style, nsv_set -nsvArray my_nsv -nsvKey $key -nsvValue $value?

As I said above, if you really want to help newbies, write an etags howto. Naming all parameters is misguided at best.

Posted by tammy m on

I still disagree. Just because Tcl procs in a language don't do it, doesn't mean code in a framework shouldn't do it. They are 2 completely different beasts.

I'll ignore the personal slam about "you are probably this" -- just not pertinent really. It's ok if we disagree and you don't even have to try to talk about what not so good a C or otherwise programmer I am;)

Writing "my_proc -userId $user_id" is not silly. It tells callers that my_proc expects a userId as an argument. That is very helpful. It could expect any sort of data structure representing a user, but it doesn't it expects a userId. 2 different things. And the docs are usually not very explicit in details on parameters and return codes. And sure if you happen to name your userId $user_id then it seems to make sense however, in real code the user id may very well be named anything else from $my_array(1) to $the_dog_ate_my_shorts and then it's not so nice. The other way, the parameter clearly enforces it.

I still think that regardless of what OpenACS is not, it should strive to be useable by as wide a user base as it can. Here's to making a widely used, user friendly, open source, web framework for the masses!

you make my point for me -- if you are naming variables based one what your dog did this morning, that is your problem and your toolkit should not attempt to bandaid it by naming its function parameters.
Posted by tammy m on
Unless I'm reading someone else's code (or many, many someone elses' code written at all different phases of the frameworks life, when variable naming standards/fashions changed) for examples and their variables are named in some or other historic fashion that makes sense in the greater scheme of what they are used for (the overall goal of the package/form/etc they are writing) but not as individual arguments to every single OACS method call in any other package whose procs they call.

For instance I'm writing a package that sells hamburgers at a drive through window (lightening up the conversation a bit;)
My variables are called drive_through_car, window_guy and order (and so). These make perfect sense in the scenario I am coding for on an overall basis and make it so that I can call my objects what they represent in the real world instead of a language or data structure specific name (user_id, write_privilege_p, whatever).

Now that makes all the code in my package easy to follow and the same object is always called the same variable name across the board. However deeper in my code where I have to call other packages, should I make it clear like this each time I call other code?
set user_id $window_guy
set object_id $cash_register
set privilege_id $cash_register_access
[permission::permission_p  $user_id $object_id $privilege_id]

Or it could look like this:
[permission::permission_p -party_id $window_guy -object_id $cash_register -privilege cash_register_access]

Of course this is just an example and permission::permission_p AFAIK requires named parameters.

It just is not always clear even if you are the ultimate God of writing perfect code (and every other who contributes to the code base is too) and it shouldn't have to be assumed that variable names will make procs understandable. Just like docs and comments aren't always there when ya need them either.

Whatever, it's just an opinion different from your own from someone who might be representative of newer users to your system... who aren't perfect, mean well, and would like any bit of help the code standards might be able to offer them in following the code.

The real problem is, you are trying make explicit showing the callee's context in the caller's context.  For one, this is not always desirable for reasons that you dismiss as unimportant.  Fine.  But for two, forcing the user to do the IDE's job is a poor idea; it is inexcusably poor when tools to perform this particular task have been around for years.

Part of being a programmer is using and creating appropriate tools; we no longer code in assembly and neither should we be coding in Notepad or fixing "problems" that only exist when you refuse to use adequate tools.

Posted by tammy m on
Sorry but I am not following what you are talking about.  "forcing the user to do the IDE's job is a poor idea;" Is this an analogy or does it apply directly to what we're talking?

I also do not understand the references to Notepad, etc. What are the "adequate tools" you are referring to and what are the problems they do or don't solve?

I have lost the point of this thread:(

Anyway, I in no way intended to get involved in some long rant/flame about our personal levels of guru-ness or intelligence...  I honestly thought opinions were being asked of others on their preferences on named parameters. I gave mine. I'm beginning to regret it:(

or just getting bored... or something...

Posted by Jerry Asher on
In referring to required parameters, well for Tcl, they are not only required to be present, but required to be present in a certain order.

Historically, OpenACS development has waivered, but leaned towards procedures in which required parameters are not named.  As Tom Jackson has mentioned, we have inverted the typical Tcl ordering and have required parameters come before named ones.

The IDE we have today changes from user to user, but one thing we all have, and it's really quite nice, is the API Browser found at /doc.  Along with the API Browser is the ad_proc procedure which allows for pretty easy, inline documentation of a tcl proc so that it can be browsed and perused with the API Browser.

So while there is certainly a learning curve to pickup the ACS, it's relatively well documented (esp. compared to other toolkits).  As such, while this forum is here to support everyone and welcome the newcomer, I would prefer the toolkit itself prefer clean, maintainable, good looking, quickly written code.  (We could still use more documentation.)

I myself think that leads to required parameters are not named and optional ones are.

As far as IDE, I always wonder what people use.  But emacs, tcltags, meta-point, nscp mode, and David Lutterkort's nsd.el extension take me quite far.  And the API Browser.

Posted by Jun Yamog on
It would be nice if we can decide which one we should use.  And stick with it.

I find it weird that this was only brought up now.  There was discussion about this, the outcome was named parameters.  I am not saying that Jonathan's reason is not valid.  But people did try to follow name parameters and even made crude docs about it.

I liked named parameters because:

- it has -foo:required, but then again if no named parameters will have a convention of all required that is ok.
- it has {-foo "bar"}, its nice to have this shortcut.
- i can add a parameter to an existing proc without breaking existing code.  But then again no name parameters can do this too.

I like no named parameters because:

- as pointed out by Jonathan, it follows the tcl way.
- it reads better for those procs with 1 or few args.

I think we must discuss this what are the plus and minuses and the core group can give its decision.  And the decision be placed in the docs, not to be digged up on this forum.  It has to be a clear guideline.

Frankly I find the comments made to Tammy inappropriate.  It is this very attitude that makes newbies go away.  Also even though that Jonathan volunteer and have cvs access to change  the api.  What about those like us who just read the docs and followed the code and use parameter::get -paramater?  Tough luck for us and our existing code will break on the next upgrade?  And we should replace existing code as well?

Where do we go?  What will be our real guideline for this?

Posted by Ola Hansson on
I am in favour of using named parameters all the time, even for required args, for the reasons that Tammy put forth.

Regardless of what the toolkit currently is, we ought to focus our thoughts on what we want it to become. Since we supposedly want it to become well-used, it's better to make the code as clear as possible for new (as well as old) programmers than to make it as frictionless as possible for the non-OpenACS Tcl croud (if you could call it a croud).

Posted by Ola Hansson on
Maybe you could call it a crowd, though ... ahem!
Damn, some of you wouldn't know good style if it bit you in the face. I'm done repeating myself. :(
Posted by Dave Bauer on
I have no problem having required parameters being unnamed. That is clearly the style that was used on ACS 4 that OpenACS is derived from.

I also am not going to care, but let's have a decision and recommened it in the documentation.

The argument was made that unnamed required parameters helps us distinguish required from optional arguments. However, given that significants part of the toolkit already uses required named parameters and given our ambition to keep the core upgradeable, we are never going to rely on a rule that named parameters are optional, no matter what decision comes out of this discussion.

Some programmers favor verbosity and readability over less typing and adherance with traditional Tcl programming style. It might be that we should avoid a simplistic decision here and instead leave the decision to the programmers on a case-by-case basis. I don't see a need to always use named parameters or always not use named parameters and in many cases we will be dealing with a mixture of both.

Verbosity and readability are not synonymous.  I've given several examples to this effect but it's like people only have the capacity for one thought: "More typing makes easier for newbies!  Ommmmmmm..."
Posted by Tom Jackson on

The problem is, this is an issue that should have been addressed when ad_proc was initially developed. Since ad_proc doesn't choke on unnamed params, they are supported. Maybe the error message which is returned when a newbie uses a proc incorrectly should provide enough information to change the call? This could be added so that it works with existing code.

Changing the core affects all code outside the toolkit, no amount of volunteer work on the core can make up for the frustration of everyone having to make the changes to their own (currently working) code.

Posted by Don Baccus on
Jonathon ... can you show us the stone tablets upon which God has written that you are the sole arbiter of programming style?  Your attitude that you're right and others are wrong because you understand good style and others don't is not helpful.

Peter makes a good point: we're not going to go change all the existing API that's been added which use named required parameters (Tom makes a strong point in this regard, too, we don't want to arbitrarily break existing third-party code for relatively trivial issues like a shift in group opinion over good style)

I'll raise your 15 years of C programming experience with my 29 years of C programming experience if it's going to come down to arguments of that sort.

I've said previously I have no objection to not naming required parameters but let's argue on the merits rather than get involved in a dick-measuring contest over who better understands programming style.

This issue was raised earlier and there were no strong objections to Open Force's proposal that we adopt the use of namespaces and named parameters (the style they used writing .LRN)

Frankly I'm more concerned with there being a hodgepodge of styles.  Any style used consistently is better than the current situation ...

  • If you read the thread I would hope you'll see that I've been trying to "argue on the merits" with concrete examples. But after the third or fourth repetition of the "verbosity = readability" mantra without any substantiation, it's gotten kind of old. And yes, there is such a thing as good style. In Tcl as well as in C; sorry if this assertion offends you but there it is.

  • I'll leave the pissing contest to you. (And tammy, who, not I, is the source of the 15 years quote.) Impressive that you were using C a year after it was first used to write the Unix kernel for the pdp-11, and four years before The C Programming Language was written.

  • "Any style used consistently is better than the current situation." But, "we're not going to go change all the existing API." Backwards compatibility is a good goal but in the absence of perfect foresight things like upgrade scripts and deprecation become necessary. I would suggest that a single style could be implemented relatively easily by leaving the old procs around for one release after they are deprecated -- then removed. e.g. if ad_parameter is deprecated in 4.6.1 and 4.6.2 is subsequently released, 4.6.3 should remove it. Deprecated functions that have a halflife of several hundred years don't cause any up-front pain, because nobody has to change code, but if you look at the progression of Java it's clear that leaving literally thousands of deprecated classes and methods around is starting to cause serious developer confusion. There's nothing wrong with making someone who doesn't want to run his code through a sed script stay on the 4 series if the 5 series has the deprecated functions he used removed. (Serious question: how many sites upgrade more than once? Is it even really a big issue with clients?)
Posted by Jun Yamog on

I think the TIP forum can be used for this?

We have stated our opinions and discussed some merits above.  Clearly I would like to have some set guideline, not a rule.  As Peter pointed out it may differ from case to case.  But a guideline must still be in place.  Otherwise the toolkit will have 2 style of doing things in the future.  We have a mix and mash in the past, we need to correct or minimize this mistake.

I am not exactly sure how things will work at TIP.  Does it work something like this?

- Jonathan puts a proposal
- People will give in feedback
- Core developers will decide
- Joel will document

If so lets try it.

Posted by Talli Somekh on
Please, someone post a TIP on this. That's the way we should encourage community standards adoption.

In terms of readability, I would like to add another constituent we need to consider - the Sys Admin.

Some of my projects, and I know there are others too, are to build applications that will be administered and maintained by an IT department. These guys are certainly not programmers let alone OACS gurus.

As a result, IMHO balancing programmer coding efficiency with non-programming readability is very attractive for implementation scenarios such as this.

This is not an argument for conventions one way or the other, just another scenario to consider.


Posted by Don Baccus on
Yep, I wrote my first C code in 1974, to change the terminal interface distributed with PDP-11 Unix to use Dec-standard full-duplex line editing rather than the half-duplex line editing style they'd copied from Multics.

That probably doesn't mean anything to anyone here other than me ...

As far as style goes, "good style" is rarely an absolute.  Within the C community itself, function headers (prototypes) as implemented in other languages were once considered verbose and redundant, a Pascal-ism if you will for the weak of mind.  Yet after C++ introduced function prototypes, the C camp finally warmed up to them, included them in ANSI C, and today the use of function prototypes is considered good style by most, but not all, C programmers.  For example the author of daemon tools apparently is old-camp and refuses to use them, but his view is nowadays the minority view.

So your high-handed "I know better" approach to issues of style shows, among other things, a certain lack of perspective.  When Open Force proposed adopting the named parameter approach, they argued among other things that it was good style ...

Posted by Randy Ferrer on

IMHO the question of style is as varied as there are developers and shops. I have seen shops that operate with absolutely no standards for coding style (disastrous for the most part) and have been privy to those who adhere and impose a coding style. The benefits of latter are obvious. The point here is that once the oacs governance is formed and oacs is officially a group, it would be a good idea for said governance to officially bless a set of style guidelines for oacs. Any packages that are part of the official distribution should follow those guidelines if the package is to be accepted in the community.

This would go a long way towards shortening learning curves as well as making code clearer for the newcomer and everyone else. OACS is not too bad in this respect - so it should not be difficult to arrive at guidelines that most community members can live with. My main point is that without a gatekeeper for this, I think it will be next to impossible to maintain a consistent coding style for OACS. Just my 2 pennies....

Posted by Jun Yamog on

I think we should move this to TIP.  I also think that Jonathan should be one to put this on TIP.

If not, then what is the coding style of OACS?

Posted by Jerry Asher on
That probably doesn't mean anything to anyone here other than me.###a few of us@Jeez you're old!
Posted by Tom Jackson on

Andrew, tcl prcs, those defined with proc, have required parameters first, because they are passed in to the proc in order. Following that are parameters which have defaults defined for them:

proc my_proc { param1 param2 {param3 "a"} {param4 "b"} } {

    # do something


But I don't see what you are talking about WRT the string and clock commands. The order is:

  • command
  • subcommand
  • switches
  • required_positional_params
  • optional_positional_params

The string command does have a few switches which require a value, just like unix command switches. And the order is the same format as unix commands. There are no named parameters in unix commands.

In contrast, db_multirow, defined via ad_proc has optional switches, followed by unnamed positional params, followed by more optional switches, followed by a required 'code_block' param, followed by an optional param:

 db_multirow [ -local ] [ -append ] [ -extend column_list ]
  var-name statement-name sql 
  [ -bind bind_set_id | -bind bind_value_list ] code_block 
  [ if_no_rows if_no_rows_block ]

The final optional param has to be prefixed with a switch that has a distinct format, missing the beginning '-'.

There can always be good reasons for doing things this way, and I'm not passing judgement on the style. I think the procedure comes with enough documentation to quickly figure out how to use it. But it isn't like tcl or unix command style.

Tom, "clock format" with it's "-format $format_string" syntax, stuck on the end where you say optional positional params would go, does not fit into your above model at all. Tcl is ad-hoc and arbitrary on this. Even in the Tcl core, the various commands and procedures follow no firm style guidelines when it comes to order or style of arguments to functions - which seems ok to me.

db_multirow, ah, good point, I'd forgotten you could define complicated syntax like that with ad_proc. (Never had any reason to use it myself.) Ok, so then IMO, when it comes to the style of passing arguments to procedures, OpenACS and Tcl are both ad-hoc.

Of course, this all fits with (and stems from) the basic free-form nature of the Tcl syntax That, roughly, the first argument on a line is always a command, and it's up to that command to do whatever the heck it wants with all the rest of the arguments, imposing any special syntax it may care to, etc.

It's rather silly to point to the few inconsistencies that exist in any large project and claim this proves that the rest of the code base follows no pattern.

All you have to do is look at how tcl "proc" works out of the box to see what the tcl pattern is.  99.9% of tcl functions are written with proc, after all.  Grasping at straws to demonstrate otherwise is wishful thinking.

No, at least some people seem to have thought that OpenACS's typical procedures defined with ad_proc somehow "reverse" the "normal" or "standard" Tcl conventions for passing arguments, switches, options, or what have you to a procedure, and at least by implication, that this is a bad thing. I don't see that at all, I don't think any convention whatsoever was "reversed", and that's mostly all I was trying to get at above...
Posted by Jeff Davis on
before anyone gets too wound up about flaunting the Tcl standards they should read the code in various tk and tcllib procs for handling flags and decide if they like the internals better there.

Personally I don't like having to roll my own parameter parsing and I like the convenience and robustness of ad_procs arg parser (which is really a side benefit and the real advantage is the documentation stanza).

Also, the abomination that is db_multirow is not a consequence of anything planned or of ad_proc or anything else, rather it is in the state it's in because it was modeled on db_foreach (which used proc_doc) and it looks the way it looks since it started life without the ad_proc arg parser, sprouted warts over time and has a combination of internal hand rolled option parsing (the above mentioned "standard" convention) and ad_proc parsing for some things that were added subsequently.

On the other hand I don't see people getting it wrong in their code so I don't think its a problem that it has some cruft.

Clearly if you define a function with proc you cannot have any optional arguments before a required one.  I think that is what Tom is referring to.