Move h() class out of framework

[SandyS1]

Helpers are one thing people are likely to extend on projects, and since the H class is a convenience extension of the base Helper class, it would make sense to move it to classes and let it be a utility class that people add on to for project-specific things, so they aren't modifying framework files.

[EliW]

So I had considered this. But I was wanting to keep the 'classes' directory completely clean, and only setup to hold project specific work. Not to have any part of the framework live within there. So that someone, when needing to update the framework itself, would only need to drop a new /framework directory in place.

Hence why everything that used to live in Classes, was removed and/or pulled back into the framework proper.

My thought process thus on this, was that if someone wanted to add other helper type methods, that they could do that inside of their own classes, or even extend Helper themselves and give it a new alias if they wish.

Versus pulling it into the classes directory.

[SandyS1]

The reason I think it doesn't belong in the framework is that it doesn't really do anything other than alias. The Framework already expresses its opinion about it existing by leaving it in Classes if it's moved there, so you don't lose anything. And you have a logical place to add helpers, the way we did in mojoLive.

[EliW]

Ah, but therein lies the rub. You are correct, all it does is provide an alias. However if you move it into classes, and encourage people to start 'adding stuff to it'. Then you blur it's line. It's now not just an alias, it's an alias 'plus stuff'.

Plus you blur the line between what's a 'framework feature' versus what is something you added/extended yourself. Keeping the 'framework features' and the 'specific application' features separated, keeps that line distinct/intact.

So you won't find yourself walking onto the 'next project using Treb', and trying to do H::myMethodIWrote() ... and wondering why it's not working. Cause 'H' is part of the framework, it should just work.

To my mind therefore, there is a bevvy of 'proper solutions' here, none of which include just 'adding more stuff to H', for any Treb based project:

1. Extending Helper yourself for your project. MyHelper perhaps, or AppHelper, whatever you wish. And then, if you feel saucy, you can make your own alias. MH:: or AH:: or just A:: ... But by doing so, you'd be reminded each time that you call this, that you aren't calling the core framework. But your own extension of it specific to your application. HOWEVER: This does still leave things more 'messy', since really, did you need to extend it? Was there a real reason you had to add those methods onto Helper? Which leads us to:

2. Just making your own 'utility method class' as/if you need it. Leave H and Helper alone. Make your own Tools class (Tools, Globals, Stuff, whatever you wanna call it), or use the name of your app. (When I was at digg, we had a class called Digg (with alias D) that was used for app-specific methods). etc. The benefit of this, is that you don't ever 'mingle' the concepts of what the framework provides versus something that you wrote for a one-off application.

3. Even better, is to move away from all of these 'general global-esque' features, when possible, and move to far more 'specific' based classes. You are correct that (insider trading here), that at mojoLive, when Helper & Utility lived inside of the /classes/ directory. That they became behemoth dumping grounds for anything/everything we ever needed. It was very lazy programming. Better is to separate any of those concerns into their own classes anyway. As a good example, I was finding a little time to hack on GridSorter just the other day. I found the need to create some methods to deal with creating & checking captcha. At mojoLive those got dumped into Helper & Utility respectively. I realized, as I started down first modifying those core classes out of habit, and then considering (1) above, and moving into (2) ... that I smacked myself up side the head. And made a separate Captcha class, cause that was the right thing to do. :)

4. And the final aspect I'll point out. Is that if a method is 'so generic' as to be generically useful across the gambit of any website (or a majority), that makes you only feel that it's proper home is in 'Helper' (or 'Utility' for that matter). Then honestly it should probably be contributed back to Treb, as part of the core framework.

shew