5 ms·

The FogBugz Plugin Architecture

25 points by df07 17y ago

ajg1977 17y ago
FogCreek still prefix their classes with 'C'? Oh Joel... :(
- df07 17y ago
  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...
  - bretthoerner 17y ago
    > 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.
    - deleted 17y ago
      [deleted]
    - gecko 17y ago
      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.
      - bretthoerner 17y ago
        Oh, global like GLOBAL. I see. I thought he just meant non-methods.
- listic 17y ago
  Please explain for the dummies: is this sort of naming convention just a fad that is out of style or has some of the latest advances in technology made it obsolete?
  - deleted 17y ago
    [deleted]
  - smanek 17y ago
    Reasonably strong typing + better IDEs have made type-naming redundant. If you don't have both those two available, go ahead and use it though.
  - dchest 17y ago
    It depends on language. In Delphi/Object Pascal the convention is/was to prefix classes with T or TProjectName. Because Pascal is case-insensitive language, classes are prefixed to avoid mixing them with variables (Cat = TCat.Create). In Objective C classes are usually prefixed with two capital letters (unique for company or project), like NSString. Because ObjC/C doesn't have namespaces, this serves the purpose of avoiding collisions with other classes that may have the same name. So yes, while it's a convention, it's here because there's no latest advances in technology to make it obsolete. In Ruby you don't have to prefix classes because there's a convention, enforced by language, to write class names in title case. In C#, the convention is not to prefix classes with letters, since it's case sensitive, has namespaces, and compiler takes care of type checking.
  - ajg1977 17y ago
    Once upon a time a Hungarian chap named Simonyi invented a system of prefixing variables with letters to describe their type. This was actually a very good idea since at the time computer programs were rapidly growing in size and complexity, and developers did not have any of the fancy IDE features nor large high-resolution screens that we take for granted today. However as with many good ideas it was became taken to excess and and variables eventually became less readable - e.g. m_spszName would be a member variable, that is static, and is a pointer to a zero-terminated string. It did not help that people often disagreed the order of prefixes, or only used a subset of the full range. With the advent of better type-checking compilers and languages, intellisense IDE features, and screens that could display more than 80 lines Hungarian notation largely faded away. The 'C' prefix was originated (I think by MFC) to signify that a type was a class. Ironically it began around the time that strict Hungarian notation began to fade out, and classes became liberally used in code. There are still many good reasons to use certain prefix's on your variable ('m' for member being the most widely used) but things like CFoo or pszName are largely antiquated relics of a past time. It just gave me a little chuckle when I saw it :)
profquail 17y ago
Instead of having your plugins be able to execute SQL commands, why not use something like ActiveRecord + NHibernate (or some other ORM) with LINQ? NHibernate 2.1 was just released with LINQ support, so you could do something like: int BugCount = Bug.Where(case => case.Id = caseId).Count(); (Where caseId is a parameter or something). It'd really simplify the API and keep you from doing safety checks on the SQL passed by the plugins. You might even be able to simply some of your "display" code to use Dynamic LINQ queries for the sorting and so forth. I've been using the ASP.NET MVC + NHibernate + ActiveRecord + LINQ "stack" for several months now (though I've been an ASP.NET developer for about five years), and I have to say that my productivity has gone way up thanks to it.
- gecko 17y ago
  FogBugz targets .NET 2, which lacks .NET Expressions; they'd have had to build their own AST model, without C# support. I wouldn't be surprised if, whenever FogBugz gets around to requiring .NET 3.5, they start supporting LINQ queries against the exposed datasets, but I wouldn't hold your breath.
  - profquail 17y ago
    Oh, that's too bad. I'm thinking about writing a plugin for FogBugz, and that would have been nice to have (it won't stop me from writing it though ;) Perhaps they could check out LINQbridge (http://code.google.com/p/linqbridge/ http://code.google.com/p/linqbridge/). I don't know if that could be adapted to work for them and ease the transition to .NET 3.5, but perhaps its something to look at. (It almost replicates LINQ on the 2.0 framework.)
kristiandupont 17y ago
I wonder if they will let people charge for their plugins and create a plugin store rather than a gallery..
- df07 17y ago
  It is planned, but not implemented yet. We're also still gauging interest. https://developers.fogbugz.com/default.asp?W133 https://developers.fogbugz.com/default.asp?W133

25 points by df07 17y ago

ajg1977 17y ago

FogCreek still prefix their classes with 'C'? Oh Joel... :(

df07 17y ago
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...
- bretthoerner 17y ago
  > 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.
  - deleted 17y ago
    [deleted]
  - gecko 17y ago
    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.
    - bretthoerner 17y ago
      Oh, global like GLOBAL. I see. I thought he just meant non-methods.
listic 17y ago
Please explain for the dummies: is this sort of naming convention just a fad that is out of style or has some of the latest advances in technology made it obsolete?
- deleted 17y ago
  [deleted]
- smanek 17y ago
  Reasonably strong typing + better IDEs have made type-naming redundant. If you don't have both those two available, go ahead and use it though.
- dchest 17y ago
  It depends on language. In Delphi/Object Pascal the convention is/was to prefix classes with T or TProjectName. Because Pascal is case-insensitive language, classes are prefixed to avoid mixing them with variables (Cat = TCat.Create). In Objective C classes are usually prefixed with two capital letters (unique for company or project), like NSString. Because ObjC/C doesn't have namespaces, this serves the purpose of avoiding collisions with other classes that may have the same name. So yes, while it's a convention, it's here because there's no latest advances in technology to make it obsolete. In Ruby you don't have to prefix classes because there's a convention, enforced by language, to write class names in title case. In C#, the convention is not to prefix classes with letters, since it's case sensitive, has namespaces, and compiler takes care of type checking.
- ajg1977 17y ago
  Once upon a time a Hungarian chap named Simonyi invented a system of prefixing variables with letters to describe their type. This was actually a very good idea since at the time computer programs were rapidly growing in size and complexity, and developers did not have any of the fancy IDE features nor large high-resolution screens that we take for granted today. However as with many good ideas it was became taken to excess and and variables eventually became less readable - e.g. m_spszName would be a member variable, that is static, and is a pointer to a zero-terminated string. It did not help that people often disagreed the order of prefixes, or only used a subset of the full range. With the advent of better type-checking compilers and languages, intellisense IDE features, and screens that could display more than 80 lines Hungarian notation largely faded away. The 'C' prefix was originated (I think by MFC) to signify that a type was a class. Ironically it began around the time that strict Hungarian notation began to fade out, and classes became liberally used in code. There are still many good reasons to use certain prefix's on your variable ('m' for member being the most widely used) but things like CFoo or pszName are largely antiquated relics of a past time. It just gave me a little chuckle when I saw it :)

profquail 17y ago

Instead of having your plugins be able to execute SQL commands, why not use something like ActiveRecord + NHibernate (or some other ORM) with LINQ? NHibernate 2.1 was just released with LINQ support, so you could do something like: int BugCount = Bug.Where(case => case.Id = caseId).Count(); (Where caseId is a parameter or something). It'd really simplify the API and keep you from doing safety checks on the SQL passed by the plugins. You might even be able to simply some of your "display" code to use Dynamic LINQ queries for the sorting and so forth. I've been using the ASP.NET MVC + NHibernate + ActiveRecord + LINQ "stack" for several months now (though I've been an ASP.NET developer for about five years), and I have to say that my productivity has gone way up thanks to it.

gecko 17y ago
FogBugz targets .NET 2, which lacks .NET Expressions; they'd have had to build their own AST model, without C# support. I wouldn't be surprised if, whenever FogBugz gets around to requiring .NET 3.5, they start supporting LINQ queries against the exposed datasets, but I wouldn't hold your breath.
- profquail 17y ago
  Oh, that's too bad. I'm thinking about writing a plugin for FogBugz, and that would have been nice to have (it won't stop me from writing it though ;) Perhaps they could check out LINQbridge (http://code.google.com/p/linqbridge/ http://code.google.com/p/linqbridge/). I don't know if that could be adapted to work for them and ease the transition to .NET 3.5, but perhaps its something to look at. (It almost replicates LINQ on the 2.0 framework.)

kristiandupont 17y ago

I wonder if they will let people charge for their plugins and create a plugin store rather than a gallery..

df07 17y ago
It is planned, but not implemented yet. We're also still gauging interest. https://developers.fogbugz.com/default.asp?W133 https://developers.fogbugz.com/default.asp?W133