I don't think this can be done as a patch it would have to be a system wide and complete change in the hardcoded API. It would also require catching the contribs before they are branched. Just too many are effected by this. Doing in partially through point point versions might work but the best case is a full point version change. Something for 4.7 maybe or if things get slow on bugs a 4.6.5 change over. Carl McDade Bèr Kessels wrote:
Hmm. Makes sense to me. But unless you make a patch for this, and you pimp that patch, this is off course not going to happen. Talk is silver , code is gold.
Bèr
Op maandag 14 maart 2005 14:32, schreef Carl McDade:
When you look at most modules there is or should be a comment that a function is a hook. This is not really good enough unless you go through the entire core and memorize all the API functions in the core and perhaps the use of those functions in core/contrib modules.
fscache_save
is a hook but you don't know this just by looking at it and it may be called in a place in the code where there is no comment. If not familiar with it then you have no idea if is part of the core or not. Potentially one could conflict the code by creating a function of the same name.
fscache_dh_save
it is now apparent that the function used is a hook and that it is part of a core module. Since non-core functions are not allowed to use the _dh, there would not be a chance of conflict when writing a module. I also know it is available for re-use.
I don't think this has to be backwards compatible ,just part of the coding conventions as a rule.
core functions : must carry _dh (or whatever)in their name
non-core functions: cannot have _dh in their name
I am partial to the way Macromedia does this because I don't have to know 1500 API functions. I just have to know that anything starting with mm_ is core. mm_function_save means that is a core function.
Carl McDade
Bèr Kessels wrote:
I am not sure if its just me, but I unbderstand nothing of your proposal. Could you rephrase this in a differnet, easier way? Remember that probably non of us use macromedea developement IDEs.
Also remember that the APIs, Theme and hooks are not maintained as backwards compatible, when we can achieve improvments by not providing that backwards compatibility. This is one of the main "features" of Drupal, something which has brought us wherre we are now. So chances we will become "fully backwards compatible", code-wise are nearly non-existant.
Bèr
Op zaterdag 12 maart 2005 16:53, schreef Carl McDade:
Maybe gotten spoiled from working with Macromedia products where everything in the core API is set with MM, but why is there no designation between drupal hook functions and private functions? Checking the docs is not useful especially given that the api changes
so
often. Frequent changes are also the reason that memorization does
not
work. Marking core hooks and other would not cost anything and would help in the creation and maintenance of contributed modules.
Changing: function mymodule_validate(&$node) {
To: function mymodule_dh_validate(&$node) {
Or: function mymodule_validate_dh(&$node) {
_dh being the core designation would make th process of updating a module easier also.
This might be a solution to a naming problem also in that all core
code
must start with the designation. So anything after that can be used including the underscore character.
Changing the hook invoke code has to be done but from the looks of it this is not a big change.
Carl McDade
Regards, Bèr Regards, Bèr