Re: Capitalization

Thanks for the detailed summary.


On Mon, Mar 18, 2013 at 8:33 AM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:

> Translating the controller class pattern is fairly obvious: it should
> be [Module]_Controller_Admin_[Something], which is then transparently
> extended as Controller_Admin_[Something].  This flows nicely with K3.
>

Ok, so Albums_Controller becomes:
  modules/gallery/classes/Controller/Albums.php

which extends:
  modules/gallery/classes/Gallery/Controller/Albums.php

and:
  modules/gallery/classes/Controller/Admin/AdvancedSettings.php

extends:
  modules/gallery/classes/Controller/Gallery/Admin/AdvancedSettings.php

That makes sense.


> Translating the helper class patterns is slightly less obvious.  Here
> are some possibilities:


> 1. Call them [Module]_Module_[Type], e.g. tag_event_Core =>
> Tag_Module_Event.  The asterisk to this approach is that, unlike every
> other class in the classes directory, these should *not* get the
> transparent-extension-enabling class added to it (e.g. "class
> Module_Event extends Tag_Module_Event {}").


> 2. Call them [Module]_[Module]_[Type], e.g. tag_event_Core =>
> Tag_Tag_Event.  This is similar to the previous approach, but keeps
> the transparent-extension-enabling class added to it (e.g. "class
> Tag_Event extends Tag_Tag_Event {}").  This means that, in the end,
> it's called by other functions as Tag_Event.  The asterisk to this
> approach is that the directory structure is a little broken.  In this
> example, the tag module would have all of its "real" class code in
> modules/tag/classes/Tag, which are transparently extended by files in
> the parent of that directory.  So, the event code would be in
> /modules/tag/classes/Tag/Tag/Event.php, and the
> transparent-extension-enabling file at
> /modules/tag/classes/Tag/Event.php, with all of its siblings being
> "real" classes instead of the thin extensions.  It works, but it
> doesn't seem clean.
>
> 3. Call them Module_[Module]_[Type], e.g. tag_event_Core =>
> Module_Tag_Event.  This has the same problem as 2, in an even
> less-idiomatic way.
>
> 4. Call them [Module]_[Type]_[Module], e.g. tag_event_Core =>
> Tag_Event_Tag, which is then transparently extended as Event_Tag.
> This doesn't seem like a great idea since examples like Rest_Gallery
> from the gallery module seem likely to clobber something in the rest
> module.
>
> 5. Call them [Module]_Module_[Type]_[Module], e.g. tag_event_Core =>
> Tag_Module_Event_Tag, which is then transparently extended as
> Module_Event_Tag.  This flows pretty well with K3, and is my current
> favorite approach.
>
> 6. Put them somewhere else and bypass the standard autoloader.  This
> has the advantage of allowing us to make the class names look less
> encumbered (e.g. tag_event_Core => tag_event), but otherwise seems to
> intentionally break all of the other Kohana conventions.
>

7.  Go with [Module][Type], eg tag_event_Core => TagEvent, which is then
transparently extended as Tag_TagEvent.  This flattens out one level of the
hierarchy and gets rid of the hierarchy altogether for modules that don't
want to make extending easy.  It has the downside of making it harder to
figure out which things are part of the Gallery-imposed infrastructure of a
module (ie - grouping the _task, _installer, etc stuff together).

I think we want to do our best to avoid requiring module developers to
understand a lot of structure.  K2 was great about that - K3 is making it
harder with all this hierarchical complexity.  I get why they did it, but
frankly the overloading mechanism was a lot less boilerplate in K2.  Now
we're basically going to have to double our file size (cry!) to make
everything overloadable.  That really sucks.

Seeing where this is going - I think that we should do two things here:

1) We should not blindly make everything overloadable.  99% (pulling that
number out of nowhere) of what we make overloadable will never be
overloaded and just adds extra cognitive pain to the app.

2) We should keep directory structures flat where possible.
 modules/tag/helpers/tag_event should become a non overloadable
modules/tag/classes/TagEvent.  If at some point there's a strong desire to
start overloading this stuff we should look really closely at *why* they
want to overload and see if there's some better mechanism.  Overloading is
likely an indication that we're doing something else wrong.

thoughts?

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar

__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]