RE: namespaces.<br><br>&nbsp; variable_get(&#39;var_name&#39;)<br>&nbsp; variable_get(&#39;var_name&#39;, &#39;namespace_name&#39;)<br><br>I think both should be valid.&nbsp; The &quot;&quot; namespace would be for legacy modules or those who
<br>don&#39;t want namespace.&nbsp; 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&#39;t think variable name stomping or &#39;sufficiently large&#39; 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> &lt;<a href="mailto:larry@garfieldtech.com">larry@garfieldtech.com</a>&gt; 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.&nbsp;&nbsp;I don&#39;t know from localization, so I&#39;ll leave it to Gabor to decide what&#39;s best for that.<br><br>The &quot;variable registry&quot; hook seems consistent with what Drupal 6 is doing.&nbsp;&nbsp;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)? :-)&nbsp;&nbsp;I&#39;m open to either that or mandated variable_set() in .install.&nbsp;&nbsp;I think the registry would be a bit easier for development (easier to add/change quickly), while mandated variable_set() would mean we don&#39;t need to add another hook to each module (less code++).
<br><br>I&#39;m not wild about the namespace concept, until I see a code sample of how I&#39;d use it.&nbsp;&nbsp;Would that replace the second parameter?&nbsp;&nbsp;variable_get(&#39;system&#39;, &#39;site_name&#39;)?&nbsp;&nbsp;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&#39;re mucking about in the variable system, the cache system recently introduced a &quot;serialized&quot; flag to specify if a given value needs to be serialized or not.&nbsp;&nbsp;(I believe the default was object/array = serialize else don&#39;t bother.)&nbsp;&nbsp;That saves the unserialization time on a string or int.&nbsp;&nbsp;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.&nbsp;&nbsp;I dare say half of the stuff stored there, probably more, is just ints and strings that don&#39;t need to be serialized.&nbsp;&nbsp;(And it would make manually setting clean URLs off easier, a common support request. &lt;g&gt;)&nbsp;&nbsp;I&#39;m not sure how that impacts the registry/install question, but consider that a feature request while you&#39;re at it.
<br><br>Hm, here&#39;s another use case I just thought of...&nbsp;&nbsp;Do we have cases where the default from variable_get() is itself dynamic, such as the return value from another function?&nbsp;&nbsp;If so, is that rare enough that we can say &quot;just use NULL there and throw in your own if statement&quot;?
<br><br>--Larry Garfield<br><br>On Thu, 3 May 2007 08:15:40 -0700, &quot;John Vandervort&quot; &lt;<a href="mailto:jvandervort@gmail.com">jvandervort@gmail.com</a>&gt; wrote:<br>&gt; Nice.&nbsp;&nbsp;I hadn&#39;t read adrian&#39;s thread before.&nbsp;&nbsp;If only I&#39;d searched on
<br>&gt; &#39;relm&#39;<br>&gt; :)<br>&gt;<br>&gt; So if we change the variable table to (system.install):<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; db_query(&quot;CREATE TABLE {variable} (<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; namespace varchar(128) NOT NULL default &#39;&#39;
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; name varchar(128) NOT NULL default &#39;&#39;,<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; value longtext NOT NULL,<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; language varchar(12) NOT NULL default &#39;&#39;,<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PRIMARY KEY (namespace, name, language)
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ) /*!40100 DEFAULT CHARACTER SET UTF8 */ &quot;);<br>&gt;<br>&gt; We&#39;d be halfway there.<br>&gt;<br>&gt; a patch to variable_get, set, del, and init... in bootstrap.inc and we&#39;d<br>&gt; maintain full backward compatibility
<br>&gt; with the current system, but allow namespace uniqueness and a helper<br>&gt; function for mass loading...<br>&gt;<br>&gt;<br>&gt;<br>&gt; On 5/3/07, Moshe Weitzman &lt;<a href="mailto:weitzman@tejasa.com">weitzman@tejasa.com
</a>&gt; wrote:<br>&gt;&gt;<br>&gt;&gt; &gt;&nbsp;&nbsp;- we can save extra typing and value passing on variable_get calls<br>&gt;&gt; &gt;&nbsp;&nbsp;- we have a hook to reuse when we need a list of variables<br>&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;to present for localization
<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; adds pluses over just using constants.<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; Sure, only using constants for default variable values could be make<br>&gt;&gt; &gt; variable usage better, but I think a hook do more just by being a
<br>&gt;&gt; &gt; central place and not a set of unrelated constants.<br>&gt;&gt;<br>&gt;&gt; i&#39;d like to see this centralized in a hook too. we&#39;ll be one step closer<br>&gt;&gt; to<br>&gt;&gt; the hierarchy that adrian proposed long ago:
<br>&gt;&gt; <a href="http://lists.drupal.org/archives/development/2006-06/msg00309.html">http://lists.drupal.org/archives/development/2006-06/msg00309.html</a><br>&gt;&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt; --<br>&gt; -&gt; JV
<br>&gt;<br>&gt;<br><br></blockquote></div><br><br clear="all"><br>-- <br>-&gt; JV