Forum OpenACS Q&A: Why is ad_parameter deprecated?

No explanation as to why it was deprecated was left. Does anyone know
why is that function deprecated?

Can we please leave a note on the ad_proc documentation section when a
-deprecated switch is used, explaining the reasons for that
function/method to be deprecated?

http://www.pinds.com/download/

/Lars

Been a bit of discussion recently about renaming functions etc... and also there appears to be (forgive me if I've misunderstood) some effort to move existing functions to namespace style...

Given the effeorts made to encourage upgradescripts etc.. following release 4.5, are people going to offer some kind of upgrade for these kinds of funtions changes etc..?

Perhaps this has already been addressed, and I've missed it, but if not then can I please ask (assuming this is the case) why functions etc are being renamed etc.. without upgrade. Obviously theres not much point making an effort to provide database upgrades if lots of the code is just going to stop working...

Again apologies if I've missed something and its already been addressed..

Incidentally why renbame a function from set_value to set.. not sure I see why?

Cheers
Simon

What is so difficult about keeping changes current, I mean really. 4.5 is barely out, everyone wants to change this and that for 4.6 and there are no upgrades scripts, no readme doc that explains all the ways my site will break when I upgrade and no good api browser that lets me look at this on another site (i.e. openacs) when I do the upgrade and find out my site is hosed.

Please lets think about the future in terms of upgrades as well as cleanups and "cool" new stuff.

I think better highlight on my top 20 list that what is listed on the list should not be applied on old code.  It must be only applied to new code.

In a thread a couple of days ago someone asked why some people use tabs to indent and some people use spaces.  Someone else joked that they were not going to get into that religious war.  There is of course a correct answer: you put aside your personal preferences and do whatever everyone else is doing, you follow the project standard.

AOLserver has a coding standard, the developers wisely decided to lift it from the Tcl code they were using rather than invent something new.  Postgres has a coding standard, they've even written their own tool which reformats the code for them to enforce it.  The Linux kernel has a coding standard, etc.  In other words, it's standard industry practice to follow a single coding style per project, for the very good reason that it increases developer productivity.

Now the toolkit has one more coding style, and is more inconsistent.  To regain consistency the rest of the API must be renamed; afteral what's so special about permissions and parameters?  Or, we've just decided that consistency doesn't matter.  Never mind that no one was asked, no one was told, the documentation has not been changed, the existing code has not been changed, there was no technical justification for namespaces, AOLserver has problems with namespaces...

I think my frustrations have been more than justified, Roberto.

In your previous response in this thread you said:

"we've now set out along the path of renaming every one of the more than TWO THOUSAND names in our Tcl api, FOR NO GOOD REASON"

And further in another response you claim that "Quite clearly, in the thread which you yourself started when you asked "should I put my procs under namespaces or not?" Don confirmed Yon's yes answer, and they're not the only ones. If that's not a (bunch of) official statements, then what is?"

You should notice that these are two different things, in my view, and that you're putting them in the same bag as if they belonged in the same bag: 1) Naming of FUTURE procs 2) *Renaming* *current* procs.

In the thread which you mention I started I asked what should I name for the _new_ packages I'm building. The answer to that was "use namespaces".

Then the ad_parameter question came along (also by me) and the issue of _renaming_ of the API came along, and it's _that_ issue that I said that nobody has said "YES, let's rename the whole toolkit to namespaces". And I'll say it again, I've not yet seen anyone saying that we should rename the whole toolkit API as you are claiming. What I have seen is people saying "Yes, use namespaces for your new packages".

There's an issue coding of standards to be resolved here, but I'll leave that for another thread.

It's worth pointing out that ad_parameter does something really useful that parameter::get does not. Namely, it lets you override package parameters in a text file.

So incremental improvements are good, but removing functionality that people want is not an improvement. Can someone assign themselves the ask of making parameter::get honor text file params ala ad_parameter?

Or convince me (and apparently Andrew and undoubtably others) that we really don't want this functionality?

As far as coding standards being good ... yes, they are. That's why we've got the "20 do and don't" thread going.

if it doesn't find it, it will revert to normal get by attempting to convert the package_key into a package_id via apm_package_id_from_key. one problem this has is that apm_package_id_from_key will barf if there is more than one instance of the package. what do people think about changing that function to "select min(package_id) from apm_packages where package_key = :package_key"? any objections?

yon.

However, I then went on to explain that I think a standard naming scheme is important, why, and how I got the idea.  As it's such wide spread practice I assumed it was the general opinion here, which seems to be the case as there is now an effort to formally record such a standard.  If standard naming is important, and there is a new naming standard, then is it such a leap to believe that the work to rename some of the existing procs will be carried forward to the rest of them?

You seem to have missed it but I also then explained why I think *not* carrying through with a new naming scheme renders any notion of creating consistency through a standard naming scheme obsurd, as the opposite of the desired effect is created.  This is another reason why I thought the plan must be to rename all -- or should I say a large percentage of -- the old procs.

Don, I think your right I must be a twit because I'm still confused.  You mention your newly developed proc, ad_form as an example which does not use namespaces.  But you also say namespaces must be used, when Roberto asked about developing new procs.  Do you mean to say that either the old established style with underscores or the new namepsace style are both acceptable?  What is the goal of introducing another naming style and enforcing it incosistently?

Could we also please have a commitment, folks not just a begruged shrug, to communicate this sort of stuff in a timely manner, with enough facts and some semblance of reasoning as appropriate, so that everyone is kept in the loop and inteligent desision making, where necessary, is actually possible?  This is my main point of frustration.

While I think new packages (real live APM packages) should use namespaces my own thinking isn't as clear in regard to the acs-tcl library.

Originally aD had the tendency to stuff just about every ad_* named proc into one or two files.  With later 3.x and 4.x work people started paying more attention to grouping logically-related procs into logically-named files ("text-html-procs.tcl", for instance).  But it's still pretty messy.

But we can't really do a massive reorganization of this stuff, we don't have the resources to change all our own packages (or at least ISTM there's more important things to spend those resources on) and of course we can't break everything ever written by our user community.

So I guess my own thinking is that restraining ourselves from renaming stuff in acs-tcl/tcl and other central services is something we should consider.

While still encouraging namespaces for new packages.

Comments?

Whoa, I step away for one day and look what happens. 😊

Just wanted to set the record straight:

Don Baccus wrote: CR Oldham who made this [ad_parameter grabbing values from a file as well as a database] but could be wrong.

Actually the code to do that was in the toolkit from the beginning. What I did was add functionality to the APM pages that shows when a parameter in the database is being overridden by a parameter in a parameter file.

Thanks for the well thought note.  I think we're fairly well on the same page (you and I, don't know about the rest).

I said it's an evolutionary process and that we should restrain ourselves from renaming just for renaming's sake (I wasn't implying that the new parameter namespace fell into this category, I know you added functionality etc).

You're saying there are a lot of things in the utilities space that could clean-up work, refactoring, and outright bug fixing and that while doing so using namespaces to better organize the code would be a good idea.

I don't see any large-scale disagreement in those two paragraphs.

Especially since when doing such cleanups and refactoring we want to encourage getting it right even if the calls change.  This frequently implies adding a new proc (so you don't break the old) and there's no reason to maintain the old name style for the new proc.

One think that's needed is a well-documented way to deal with deprecated procs and their disappearance.  Removing them one or two releases in the future after ample documentation that they've been deprecated and after explaining why.  That sort of thing.