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

Yep, that's my thought, too.  I've been earmarking a few things that should
be changed, but have been trying to stay solely focused on translating all
of the class/file names into K3-ese.

Take care,
Shad

On 26 March 2013 17:41, Bharat Mediratta <[email protected]> wrote:

>
> Outstanding.  This advances the issue I've been (slowly!) working on which
> is to sort out the identity provider code.  I suspect that we want to
> overhaul it, but there will be so many other issues that I'd like to get it
> working for now before we redesign it.
>
> -Bharat
>
>
> On Tue, Mar 26, 2013 at 5:57 AM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:
>
>> 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 ]