Re: Gallery's K3 class name/dir/file conventions (was "Capitalization")

+devel


On Wed, Mar 20, 2013 at 11:41 AM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:

> Hey Bharat,
>
> Hmm, I'm not sure I follow your recent round of changes.
>
> --
>
> First, the general case, i.e. ignoring the Gallery-overloaded files
> (event, theme, etc.).  The typical pattern used in Kohana (and in the K3
> work on the Gallery module to date) is that we had *one* level of hierarchy
> that holds all the real code, then populate its parent directory with
> extensions.
>
> Example: if this directory was called "Parent" you'd have:
>   class File extends Parent_File {}
>   class Child_File extends Parent_Child_File {}
>
> For the Gallery module, we have:
>   class Controller_Albums extends Gallery_Controller_Albums {}
>   class Module extends Gallery_Module {}
>
> The sketch you have below would have:
>   class Controller_Tag extends Tag_Core_Controller_Tag {}
>
> ... which to me seems even more confusing.  Why not just move the stuff
> out of core and into the main Tag directory, then:
>   class Controller_Tag extends Tag_Controller_Tag {}
>
> The name of this "Tag" directory doesn't need to be kept track of since
> it's irrelevant to anyone, unless they want to overload it with:
>   class Foo_Controller_Tag extends Tag_Controller_Tag {}
>
> ... in which case they can look it up themselves :-).  Still, having a
> nice pattern to set as precedent is good.
>

I'm having trouble keeping it straight myself!   That's why I've been
working on these tree representations so that I can make sure that I really
understand wtf I'm talking about.  So basically my struggle was trying to
figure out how to not have a namespace collision when we implement
Tag_Event.php because that would necessitate a classes/Tag subdir that
contains extensions as opposed to overloads, which means that we'd need a
*different* dir (in my example classes/Core/Tag/Event.php) to house the
real code.  But I like your suggestion below.


>  --
>
> Next, the specific case of Gallery-overloaded things.  In the sketch
> below, we have classes called Tag_Event, Tag_Theme, etc.  Two points:
> - these can't be overloaded, which means modules can't modify each other
> (not a big loss worth restructuring everything over, but still...).
> - it'd require telling Gallery to look for something called Tag_Event and
> not tag_Event or TAG_Event.  This may seem silly for tag, but becomes more
> important with module directory names like pdf, tag_albums, etc.
>
> So, my thoughts:
> - it'd be nice if these follow the same overloading class pattern as the
> general case, and would likely make life easier.
> - it'd be annoying if the code were in Tag_Tag_Event, as it'd be
> overloaded in Tag_Event and the overloading file would sit in the same
> place as real code.
>
> My proposal:
> - put the real code in either Tag_TagEvent or Tag_EventTag, which then
> gets overloaded as TagEvent or EventTag.  These maintain the same generic
> overloading pattern (nice) and the same idea that 100% of real code goes in
> /classes/Tag and is 100% extended in /classes (*very* nice for code
> browsing without scaling through hierarchy).
> - tell module.info that tag's class identifier is Tag.  This doesn't seem
> like too much of an ask, and lets Gallery know to look for TagEvent or
> EventTag instead of TAGEvent or EventTAG.
>

So a couple of points:
1) I'm not going to worry about capitalization of module names.  If we have
case sensitivity issues, let's just rename the modules to be of the ucfirst
format (eg [A-Z][a-z]*).  So modules/tag would become modules/Tag.  Also,
it will no longer be easy to have an underscore in your module name so
unless you're into wizardry and/or masochism.  K3 modules seem to use a
hypen now.

So my argument is that it should not be necessary to worry about adding a
new restriction in the module.info file.  This the benefit of an
opinionated system - there's only one way to do it hence you don't have to
specify which way you're using...


> --
>
> The file I attached is an sh script I made that does all the work of
> making the extension files for us.  For example, you could run
> "autoextend.sh modules/gallery/classes/Gallery" and it'd make all of the
> extension files in modules/gallery/classes.  As the guy who manually wrote
> 71 of these already, I look forward to using this to write the other 100+
> we need to finish the K3 conversion :-).
>

Hearty +1 for you to have and use a script for this migration.  I'm just
against making it part of the standard development process.  Smart devs
will roll their own.  Regular devs will just clone stuff and work with it...

Ok.  Let's see if I understand wtf I'm talking about.  Here's a new
picture.  Some note:

1) this is all K3.  But I broke the extension layer out from the
implementation layer into a separate tree
2) there's a 1:1 mapping - everything is extendable (including the
installer!)
3) it's flatter than what I had before
4) I probably unnecessarily have links from the old to the new inline below.

classes                                                classes/Tag
|-- Controller       |-- Controller
|   |-- Admin       |   |-- Admin
|   |   `-- Tags.php -> Tag/Controller/Admin/Tags.php  |   |   `-- Tags.php

|   |-- Tag.php -> Tag/Controller/Tag.php       |   |-- Tag.php
|   |-- TagName.php -> Tag/Controller/TagName.php      |   |-- TagName.php

|   `-- Tags.php -> Tag/Controller/Tags.php       |   `-- Tags.php
|-- Model       |-- Model
|   `-- Tag.php -> Tag/Model/Tag.php       |   `-- Tag.php
|-- Rest       |-- Rest
|   |-- Item.php -> Tag/Rest/Item.php       |   |-- Item.php
|   |-- ItemTags.php -> Tag/Rest/ItemTags.php       |   |-- ItemTags.php
|   |-- Items.php -> Tag/Rest/Items.php       |   |-- Items.php
|   |-- TagItem.php -> Tag/Rest/TagItem.php       |   |-- TagItem.php
|   |-- TagItems.php -> Tag/Rest/TagItems.php       |   |-- TagItems.php
|   `-- Tags.php -> Tag/Rest/Tags.php       |   `-- Tags.php
|-- Tag.php -> Tag/Tag.php       |-- Tag.php
|-- TagBlock.php -> Tag/TagBlock.php       |-- TagBlock.php
|-- TagEvent.php -> Tag/TagEvent.php       |-- TagEvent.php
|-- TagInstaller.php -> Tag/TagInstaller.php       |-- TagInstaller.php
|-- TagRest.php -> Tag/TagRest.php       |-- TagRest.php
|-- TagRss.php -> Tag/TagRss.php       |-- TagRss.php
|-- TagTask.php -> Tag/TagTask.php       |-- TagTask.php
`-- TagTheme.php -> Tag/TagTheme.php       `-- TagTheme.php

did I get it right?

------------------------------------------------------------------------------
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 ]