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

Hey everyone,

I just finished performing the same class/file move/rename/search/replace
operation on the user module.  Also, I made some tweaks to the gallery
module to reflect this (in particular with IdentityProvider and associated
files) and updated PHPass.

At this point, I *think* all of the files in the gallery and user modules
should talk to each other - all of the interfaces, extensions, classes, and
abstractions seem to be consistent between the two!  All of the
class/filename changes are documented in the Google spreadsheet.  I've also
compiled a little summary at the end of this email.

While this process is fresh in my mind and I'm on a roll, I'm probably
going to the same thing for the rest of the modules before diving into
Formo...

Take care,
Shad

----

How Identity and IdentityProvider got translated (typical cases):

Old class: /modules/gallery/helpers/identity.php --> class identity_Core
New class: /modules/gallery/classes/Gallery/Identity.php --> class
Gallery_Identity
Extension: /modules/gallery/classes/Identity.php --> class Identity extends
Gallery_Identity

Old class: /modules/gallery/libraries/IdentityProvider.php --> class
IdentityProvider_Core
New class: /modules/gallery/classes/Gallery/IdentityProvider.php --> class
Gallery_IdentityProvider
Extension: /modules/gallery/classes/IdentityProvider.php --> class
IdentityProvider extends Gallery_IdentityProvider

How IdentityProvider_Driver stuff got translated (the main driver keeps its
class name):

Old class: /modules/gallery/libraries/drivers/IdentityProvider.php -->
interface IdentityProvider_Driver
New class: /modules/gallery/classes/Gallery/IdentityProvider/Driver.php -->
interface Gallery_IdentityProvider_Driver
Extension: /modules/gallery/classes/IdentityProvider/Driver.php -->
interface IdentityProvider_Driver extends Gallery_IdentityProvider_Driver

Old class: /modules/user/libraries/drivers/IdentityProvider/Gallery.php -->
class IdentityProvider_Gallery_Driver implements IdentityProvider_Driver
New class: /modules/user/classes/User/IdentityProvider/Gallery.php -->
class User_IdentityProvider_Gallery implements IdentityProvider_Driver
Extension: /modules/user/classes/IdentityProvider/Gallery.php --> class
IdentityProvider_Gallery extends User_IdentityProvider_Gallery

How Group_Definition stuff got translated (removed from main driver, given
new class name):

Old class: /modules/gallery/libraries/drivers/IdentityProvider.php -->
interface Group_Definition
New class:
/modules/gallery/classes/Gallery/IdentityProvider/GroupDefinition.php -->
interface Gallery_IdentityProvider_GroupDefinition
Extension: /modules/gallery/classes/IdentityProvider/GroupDefinition.php
--> interface IdentityProvider_GroupDefinition extends
Gallery_IdentityProvider_GroupDefinition

Old class: /modules/user/models/group.php --> class Group_Model_Core
extends ORM implements Group_Definition
New class: /modules/user/classes/User/Model/Group.php --> class
User_Model_Group extends ORM implements IdentityProvider_GroupDefinition
Extension: /modules/user/classes/Model/Group.php --> class
Model_Group extends User_Model_Group

How User_Definition stuff got translated (removed from main driver, given
new class name):

Old class: /modules/gallery/libraries/drivers/IdentityProvider.php -->
interface User_Definition
New class:
/modules/gallery/classes/Gallery/IdentityProvider/UserDefinition.php -->
interface Gallery_IdentityProvider_UserDefinition
Extension: /modules/gallery/classes/IdentityProvider/UserDefinition.php -->
interface IdentityProvider_UserDefinition extends
Gallery_IdentityProvider_UserDefinition

Old class: /modules/user/models/user.php --> class User_Model_Core extends
ORM implements User_Definition
New class: /modules/user/classes/User/Model/User.php --> class
User_Model_User extends ORM implements IdentityProvider_UserDefinition
Extension: /modules/user/classes/Model/User.php --> class
Model_User extends User_Model_User



On 25 March 2013 18:08, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:

> Okay, 1 and 2 are done.  Also, the Google spreadsheet is up-to-date with
> all of the changes.
>
> My search'n'replace operation managed to make about 2800 changes!
>  Hopefully that should cut down on wrote tasks down the line :-)
>
> Take care,
> Shad
>
>
> On 25 March 2013 01:17, Bharat Mediratta <[email protected]> wrote:
>
>>
>> All looks good for me.  If you miss a few or get a few wrong it's no big
>> deal, we'll be able to figure them out from context and fix them up.
>>
>>
>> On Sun, Mar 24, 2013 at 3:34 PM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:
>>
>>> Hey Bharat,
>>>
>>> Woohoo - I think we've finally arrived on the same page!  Good
>>> conversation, though... I feel like we both figured out a lot of nuances in
>>> the process.  Onward!
>>>
>>> My roadmap for the near future:
>>> 1. Finish moving around the remaining files in the gallery module
>>> (tonight)
>>> 2. Fire up a module-wide grep to try and autofix as much as I can to
>>> avoid changing every class/file name by hand (tomorrow)
>>> 3. Do the same thing to the user module (next couple days)
>>> 4. Start getting up to speed on Formo (afterward)
>>>
>>> If it helps your workflow, I can invert the order of 2 and 3...
>>>
>>> For #2, I could use a little input.  For class names, I'll grep for the
>>> following patterns (not yet carefully regex-ized, but you get the idea):
>>> 1. class::
>>> 2. new Class
>>>
>>> Also, I'll look for these, but check them one by one:
>>> 1. call_user_func, call_user_func_array
>>> 2. $classvar::
>>> 3. {$foo . "bar"}::
>>> 4. new $foo
>>> 5. new {$foo. "bar"}
>>> 6. class_exists, method_exists
>>>
>>> Additionally, I'll look for other files (media, views), which I think
>>> all occur within double or single quotes.  I may look for View( just to be
>>> sure I got all the views.
>>>
>>> Any others you can think of that'd be useful to grab?
>>>
>>> Take care,
>>> Shad
>>>
>>>
>>> On 24 March 2013 19:34, Bharat Mediratta <[email protected]> wrote:
>>>
>>>>
>>>> On Sat, Mar 23, 2013 at 3:21 PM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:
>>>>
>>>>> If we're sticking with Kohana's functions and not making a
>>>>> wildcard-savvy loader, then this conversation is kinda moot, but for fun...
>>>>>
>>>>> <pseudo-philosophical tangent>
>>>>> I feel like there are three different cases here:
>>>>> 1. Not require a rule. (make the wildcard-savvy loader)
>>>>> 2. Require a rule. (be opinionated and enforce one way to do it)
>>>>> 3. Require a rule and make you define it. (extra line in module.info)
>>>>>
>>>>> While there are certainly arguments why 2 is better than 3, in the
>>>>> general case, it seems like 1 could often be better than 2, no?
>>>>> </pseudo-philosophical tangent>
>>>>>
>>>>
>>>> It's not clear to me when that would be the case - so I worry that it's
>>>> flexibility for flexibility's sake.  I'm ok with that if it doesn't come at
>>>> a cost, but in this case it makes the explanation harder.  For example,
>>>> it's easier for me to say "create modules/tag/classes/TagEvent.php and put
>>>> this in it" vs. saying "create a file in module/tag/classes that ends in
>>>> Event.php, like TagEvent.php and put this in it".  I'd probably just tell
>>>> people to use TagEvent in that case.  So then most people would follow this
>>>> convention - and then what would be the need for a different option?
>>>>
>>>> I'm open to this - just want to understand the value proposition.
>>>>
>>>>
>>>>>  I'm a little mixed on this.  Some thoughts:
>>>>>> - I can't tell if I like the separate subdir or not.  Frankly, that
>>>>>> implies that there's something to separate from, but many modules can do
>>>>>> everything they need to do with just and event handler and a block, etc.
>>>>>>
>>>>>
>>>>> Personally, I do.  To me, it has a similar significance to Controller
>>>>> or Model, in the sense that the names of their functions have special
>>>>> meanings outside of the class itself.  This is not the case, for example,
>>>>> for the Tag.php helper, which is why it shouldn't be in any subdir.
>>>>>
>>>>
>>>> I'm definitely coming around to this idea.  I haven't heard a name that
>>>> I like, yet though.  "Gallery" is used.  "Module" is too close to "Model".
>>>>  "Hook" is the best I've heard but I'm mildly worried that there'll be
>>>> cognitive conflict with the fact that some things inside that directory
>>>> won't be "hooks" per se (tasks, etc).  But the more I think about it the
>>>> more I like it.
>>>>
>>>>
>>>>> I think by now I'm convinced of all points you just made, with the
>>>>> sole exception being the separate directory for Gallery-specific stuff.  I
>>>>> think it gives a meaningful distinction between it and the other stuff.
>>>>>  Also, it'd give us the added benefit of being able to change our mind at a
>>>>> later date should someone decide to build an even-more-optimized,
>>>>> wildcard-capable loader.
>>>>>
>>>>
>>>> Agreed.  Let's go with Hook for now and then if we come up with a
>>>> better name before launch it should be easy to just fix up everything.
>>>>  Onwards!
>>>>
>>>>
>>>>> On a semi-related note, how do we feel about underscores in "views"
>>>>> names?  I like the idea of adding a teeny bit of hierarchy like you did
>>>>> with the Tag example (certainly no more than 1 level), and that removes a
>>>>> decent number of them, but not all.  Example: is
>>>>> /modules/gallery/views/admin/advanced_settings.php fine?  My vote is yes,
>>>>> personally...
>>>>>
>>>>
>>>> Underscores don't seem to mean anything in view names, eg:
>>>>
>>>>   modules/userguide/views/userguide/examples/hello_world_error.php
>>>>
>>>> That'd be loaded as "userguide/examples/hello_world_error.php" as far
>>>> as I can tell.  I can't find good examples of this - but I also don't think
>>>> that it makes sense for it to be "admin/advanced/settings.php" so I also
>>>> vote for "admin/advanced_settings.php".  If we find a better model in the
>>>> future, renaming all this stuff should be easy and backwards compatible.
>>>>
>>>> OK!  I think this means it's time to write some code?  I'm going to get
>>>> going on seeing if I can sort out the IdentityProvider code...
>>>>
>>>>
>>>
>>
>

------------------------------------------------------------------------------
Own the Future-Intel&reg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d

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