The FogBugz Plugin Architecture

Re:The FogBugz Plugin Architecture by df07 on Monday August 10, 2009 @04:51PM (#754019)

I agree this is one of the sillier Hungarian notation conventions, but with that said it does help with a couple things. First, I can look at the file CBug.was and know it contains a class, vs util.was which contains global utility functions (ugh, global functions, I know). Second, in .NET we've adopted the convention that "C" classes are meant to be instantiated, and non-"C" classes aren't. So the FogCreek.FogBugz.Url class just has some static methods to generate URLs, whereas FogCreek.FogBugz.CBug is actually an object that you instantiate and do stuff with.

I'd never use it on a new project, but it's not 100% worthless...

[ Parent | on HN ]

Re:The FogBugz Plugin Architecture by bretthoerner on Monday August 10, 2009 @05:39PM (#754124)

> ugh, global functions, I know

> FogCreek.FogBugz.Url class just has some static methods to generate URLs

Honest question, why does one gross you out and not the other? I don't do .NET and in the Python community "global functions" aren't looked down on, so I'm just trying to learn something.

[ Parent | on HN ]

Re:The FogBugz Plugin Architecture by gecko on Monday August 10, 2009 @05:53PM (#754154)

Wasabi--which is what FogBugz is (mostly) written in--has honest-to-goodness global functions, which are very different beasts from Python's module-scoped functions (unless you import * from one). I might be wrong, but I suspect that's what bothers df07.

[ Parent | on HN ]

Re:The FogBugz Plugin Architecture by bretthoerner on Monday August 10, 2009 @06:51PM (#754262)

Oh, global like GLOBAL. I see. I thought he just meant non-methods.

[ Parent | on HN ]