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

Oops, forgot to hit reply-all earlier...

But yes, it looks our our nearly-simultaneous emails are more-or-less on
the same page with dir structure!  The only diffs are re: rest, which I
don't think are central to the conversation anyway.

Having thought through all of this, a new (and perhaps better) idea on how
to handle the Gallery-specific stuff is starting to take shape in my mind.
Headed to sleep now, but will think more about it tomorrow and write
something up.

BTW, nicely done on pushing out Rive Gauche!  That's one less branch to
break our brains.

Take care,
Shad

Sent from my Swiss Army Phone
On Mar 21, 2013 12:01 AM, "Bharat Mediratta" <[email protected]> wrote:

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