[Gtk-sharp-list] Interface Name Patch
Wed, 26 May 2004 18:30:11 -0400
As far as my opinion counts, and I dont know exactly how far that is, I
think this is a bad idea.
My understand of implementing a GInterface is that its very different
than implementing a C# interface.
Looking at vlad's recent patch to do so basically proves my point.
Breaking this much code for no appreciable gain to me seems to make
little to no sense. I don't think a user type should ever implement a
GInterface directly, as it just wont work the way you want it to (yet,
maybe later). Therefore giving it the preceding I gives you no API
clarity, and just breaks almost every single Gtk# app in existence. For
If Gtk# is rough around the edges only because we dont have an I in
front of interfaces that you should *never* implement directly then I
would say our job here is done, and we can pack up and go home early.
Basically, you should treat these interfaces as abstract classes, not
And believe it or not, existing gtk+ developers moving to gtk# are one
of the prime targets of gtk#.
On Wed, 2004-26-05 at 13:37 -0700, Samuel Kaufman wrote:
> On Wed, 2004-05-26 at 12:04, Mike Kestner wrote:
> > On Tue, 2004-05-25 at 22:12, Samuel Kaufman wrote:
> > > This patch will make the naming of interfaces consistent within Gtk#,
> > > following the core class library's naming scheme. (ITheName)
> > Here's a long answer to a small suggestion. ;-)
> Some valid points.
> As far as wasted effort goes, I'd be willing to do all the work
> (documentation, code, fixing projects like Muine/MonoDevelop, etc.)
> myself. I'd just be sitting on around playing the guitar, anyway. At
> least this is a bit more productive. ;-)
> Microsoft's entire .NET API is much nicer than the OSS alternatives.
> The sole reason for this is that they took care to make the API appear
> as though everything had been written in managed code from the
> beginning. It's very professionally done. Gtk# is nice, but a bit
> rough around the edges. Personally, I would love to see development
> with Mono be every bit as pleasant an experience as it is with Microsoft
> I can understand the benefits of being similar to the C API, but if a
> developer wanted to use the C API, they'd be writing C code. (On a
> related note, I plan on working on documentation for Gtk# over the
> summer with the Gtk+ docs as a guide. This should seriously ease
> beginner's pain.)
> I still believe it should be done now, before the API freeze and before
> applications targeting Mono reach an officially stable state. If it's
> not done now, it'll just be that much longer before it CAN be done
> again, after all.