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

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

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