<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">I'd request/recommend that if all of this goes in drupal 6, we change the function name at the same time. Changing the function this drastically without changing its signature can be a bit dangerous. <DIV><BR><DIV><DIV>On May 3, 2007, at 8:56 AM, John Vandervort wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite">RE: namespaces.<BR><BR> variable_get('var_name')<BR> variable_get('var_name', 'namespace_name')<BR><BR>I think both should be valid. The "" namespace would be for legacy modules or those who <BR>don't want namespace. The second would be preferred and allow uniqueness and loading of the entire<BR>namespace in a single db call.<BR><BR>I just don't think variable name stomping or 'sufficiently large' variable names are a good thing:) <BR><BR><BR><BR><DIV><SPAN class="gmail_quote">On 5/3/07, <B class="gmail_sendername">Larry Garfield</B> <<A href="mailto:larry@garfieldtech.com">larry@garfieldtech.com</A>> wrote:</SPAN><BLOCKQUOTE class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <BR>+1 to centralized defaults. I don't know from localization, so I'll leave it to Gabor to decide what's best for that.<BR><BR>The "variable registry" hook seems consistent with what Drupal 6 is doing. We have a menu callback registry (hook_menu), a forms registry (hook_forms), we now have a theme registry (hook_theme), why not a variable registry (hook_variables)? :-) I'm open to either that or mandated variable_set() in .install. I think the registry would be a bit easier for development (easier to add/change quickly), while mandated variable_set() would mean we don't need to add another hook to each module (less code++). <BR><BR>I'm not wild about the namespace concept, until I see a code sample of how I'd use it. Would that replace the second parameter? variable_get('system', 'site_name')? Remember that modules call variables across the module-line all the time, so that needs to be kept as simple as possible. <BR><BR>As long as we're mucking about in the variable system, the cache system recently introduced a "serialized" flag to specify if a given value needs to be serialized or not. (I believe the default was object/array = serialize else don't bother.) That saves the unserialization time on a string or int. Given that the variable table is loaded completely on a page load, I think the same thing could work here to reduce the amount of deserialization required. I dare say half of the stuff stored there, probably more, is just ints and strings that don't need to be serialized. (And it would make manually setting clean URLs off easier, a common support request. <g>) I'm not sure how that impacts the registry/install question, but consider that a feature request while you're at it. <BR><BR>Hm, here's another use case I just thought of... Do we have cases where the default from variable_get() is itself dynamic, such as the return value from another function? If so, is that rare enough that we can say "just use NULL there and throw in your own if statement"? <BR><BR>--Larry Garfield<BR><BR>On Thu, 3 May 2007 08:15:40 -0700, "John Vandervort" <<A href="mailto:jvandervort@gmail.com">jvandervort@gmail.com</A>> wrote:<BR>> Nice. I hadn't read adrian's thread before. If only I'd searched on <BR>> 'relm'<BR>> :)<BR>><BR>> So if we change the variable table to (system.install):<BR>><BR>> db_query("CREATE TABLE {variable} (<BR>> namespace varchar(128) NOT NULL default '' <BR>> name varchar(128) NOT NULL default '',<BR>> value longtext NOT NULL,<BR>> language varchar(12) NOT NULL default '',<BR>> PRIMARY KEY (namespace, name, language) <BR>> ) /*!40100 DEFAULT CHARACTER SET UTF8 */ ");<BR>><BR>> We'd be halfway there.<BR>><BR>> a patch to variable_get, set, del, and init... in bootstrap.inc and we'd<BR>> maintain full backward compatibility <BR>> with the current system, but allow namespace uniqueness and a helper<BR>> function for mass loading...<BR>><BR>><BR>><BR>> On 5/3/07, Moshe Weitzman <<A href="mailto:weitzman@tejasa.com">weitzman@tejasa.com </A>> wrote:<BR>>><BR>>> > - we can save extra typing and value passing on variable_get calls<BR>>> > - we have a hook to reuse when we need a list of variables<BR>>> > to present for localization <BR>>> ><BR>>> > adds pluses over just using constants.<BR>>> ><BR>>> > Sure, only using constants for default variable values could be make<BR>>> > variable usage better, but I think a hook do more just by being a <BR>>> > central place and not a set of unrelated constants.<BR>>><BR>>> i'd like to see this centralized in a hook too. we'll be one step closer<BR>>> to<BR>>> the hierarchy that adrian proposed long ago: <BR>>> <A href="http://lists.drupal.org/archives/development/2006-06/msg00309.html">http://lists.drupal.org/archives/development/2006-06/msg00309.html</A><BR>>><BR>><BR>><BR>><BR>> --<BR>> -> JV <BR>><BR>><BR><BR></BLOCKQUOTE></DIV><BR><BR clear="all"><BR>-- <BR>-> JV</BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>