[drupal-devel] Why is there no designation between hooks and private functions in a module?

Bèr Kessels berdrupal at tiscali.be
Mon Mar 14 13:51:33 UTC 2005


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
-- 
 [ Bèr Kessels | Drupal services www.webschuur.com ]



More information about the drupal-devel mailing list