It makes everything simpler!



  • I recently found in our codebase a monster god class containing just over 800 methods, split across 57 files.  The monster's superclass implementation contains a comment stating that, "All subclasses must be partial classes of same class to make coding simpler and eliminate overhead of too many classes."

    Apparently since the application only has to interface with a single class to do anything at all, it just makes everything simpler.  This is what offshoring gets you.



  • @Smitty said:

    I recently found in our codebase a monster god class containing just over 800 methods, split across 57 files.
     

    Wow, Monster Cables is getting into coding. Did they change the font color to gold, and document how it helps filter "dirty bits" for better rounded cycles?



  • @Smitty said:

    I recently found in our codebase a monster god class containing just over 800 methods, split across 57 files.  The monster's superclass implementation contains a comment stating that, "All subclasses must be partial classes of same class to make coding simpler and eliminate overhead of too many classes."

    Apparently since the application only has to interface with a single class to do anything at all, it just makes everything simpler.  This is what offshoring gets you.

    TRWTF is partial classes.

     Protip: If your class is so large and complex that it requires more than one file to implement it in an understandable way, you're doing it wrong.

     



  • @Mason Wheeler said:

    Protip: If your class is so large and complex that it requires more than one file to implement it in an understandable way, you're doing it wrong.

    If I have a class with some static and some non-static methods, I put them in different partials. So I think you're full of shit.

    I would say, though, if you have more than 3 partials of the same class, you're almost certainly doing it wrong. 57 is right out.



  • @some strange coder that smitty knows said:

    "All subclasses must be partial classes of same class to make coding simpler and eliminate overhead of too many classes."
     

    What?

    Not knowing C# dev I don't understand partial classes, but either way - is there any situation where this rule actually has the intended effect?



  • @Cassidy said:

    Not knowing C# dev I don't understand partial classes, but either way - is there any situation where this rule actually has the intended effect?

    C# allows you to split the definition of a single class across n number of files.  In this case, they've split across 57 files.

    I tend to agree with Mason that partials are TRWTF, but properly applied they can come in handy.  I knew a guy once who would use partials to add functionality to generated code.  In this way the generated part of the class could be excluded from static analysis to avoid useless warnings.

    Still, these guys are full of shit.



  • @Cassidy said:

    What?

    Not knowing C# dev I don't understand partial classes, but either way - is there any situation where this rule actually has the intended effect?

    No. In fact, that proclamation basically sums to: "don't use any classes at all." Since you're putting the entire program in the same namespace.

    I look forward to the pedantic dickweeds who are going to ignore the word "basically" in that last paragraph and come at me with a bunch of technical reasons why this is not equivalent to not using classes at all.



  • @blakeyrat said:

    No. In fact, that proclamation basically sums to: "don't use any classes at all." Since you're putting the entire program in the same namespace.
     

    Yeahhhhh.... it felt like that, but I honestly thought my lack of C# knowledge meant it couldn't possibly be that.

    @blakeyrat said:

    I look forward to the pedantic dickweeds who are going to ignore the word "basically" in that last paragraph and come at me with a bunch of technical reasons why this is not equivalent to not using classes at all.

    It's your magnetic personality that attracts them. Purely a force of nature; it can't be stopped.


  • Discourse touched me in a no-no place

    @Smitty said:

    I recently found in our codebase a monster god class containing just over 800 methods, split across 57 files.  The monster's superclass implementation contains a comment stating that, "All subclasses must be partial classes of same class to make coding simpler and eliminate overhead of too many classes."

    Apparently since the application only has to interface with a single class to do anything at all, it just makes everything simpler.  This is what offshoring gets you.

    By "overhead" whoever wrote that meant "I'm not smart enough how to figure out how to use multiple classes and not have all my fields and methods be static."



  • @blakeyrat said:

    If I have a class with some static and some non-static methods, I put them in different partials. So I think you're full of shit.

    I don't, so I think you're full of shit.
    No, seriously, partials are a great way to make stuff harder to follow. Everyone should use them.



  • @blakeyrat said:

    If I have a class with some static and some non-static methods, I put them in different partials. So I think you're full of shit.

    I don't, so I think you're full of shit.
    No, seriously, partials are a great way to make stuff harder to follow. Everyone should use them.



  •  So... what are partials?  Are they like the inverse of what are called "mixins" in Python?



  • @blakeyrat said:

    @Cassidy said:

    What?

    Not knowing C# dev I don't understand partial classes, but either way - is there any situation where this rule actually has the intended effect?

    No. In fact, that proclamation basically sums to: "don't use any classes at all." Since you're putting the entire program in the same namespace.

    I look forward to the pedantic dickweeds who are going to ignore the word "basically" in that last paragraph and come at me with a bunch of technical reasons why this is not equivalent to not using classes at all.

    Solution: one file, one namespace, one class, and lots and lots of regions. In some countries if you can spin that you do "regional development" you can even get tax credits.



  • @sprained said:

     So... what are partials?  Are they like the inverse of what are called "mixins" in Python?

    It appears not.
    It is possible to split the definition of a class or a struct, or an interface over two or more source files. Each source file contains a section of the class definition, and all parts are combined when the application is compiled. There are several situations when splitting a class definition is desirable:

    • When working on large projects, spreading a class over separate files allows multiple programmers to work on it simultaneously.
    • When working with automatically generated source, code can be added to the class without having to recreate the source file. Visual Studio uses this approach when creating Windows Forms, Web Service wrapper code, and so on. You can create code that uses these classes without having to edit the file created by Visual Studio.
    • To split a class definition, use the partial keyword modifier, as shown below:
    I'm not sure about that third bullet point however.

  • Discourse touched me in a no-no place

    @Smitty's Fuckwit Colleague said:

    "All subclasses must be partial classes of same class to make coding simpler and eliminate overhead of too many classes."

    So someone who obviously doesn't understand OOP is not only producing code, but designing classes. This is a sure sign that we've made programming too easy. When I'm elected world dictator, I will require all programmers to produce working Haskell code before being allowed to use any other programming language.



  • @PedanticCurmudgeon said:

    When I'm elected world dictator, I will require all programmers to produce working Haskell code before being allowed to use any other programming language.
     

    I'm okay with this, because I'll be learning Haskell on your dime instead of having to make time myself.



  • @PedanticCurmudgeon said:

    So someone who obviously doesn't understand OOP is not only producing code, but designing classes. This is a sure sign that we've made programming too easy. When I'm elected world dictator, I will require all programmers to produce working Haskell code before being allowed to use any other programming language.

    This beast disturbed me enough that I had to write the offshore team and ask WTF they were thinking. The response I got was that "this design is highly modular and eases implementation, as developpers (sic) can add/remove partial class components when they want".

    FML.



  • @PedanticCurmudgeon said:

    So someone who obviously doesn't understand OOP is not only producing code, but designing classes.
     

    Or, more (accurately | pedantically) - one single class.

    Are partials the equivalent of an "include" then? Just being able to split one big class out into separate files?

    Can those partials be used in other classes? Thinking about code re-use, or trying to draw parallels with other languages.



  • @Cassidy said:

    Just being able to split one big class out into separate files?
     

    Yes. That is all there is to it. It has nothing to do with interfaces or subclassing.

    It's syntactic sugar, in a way.

    It also really handy because when you're .Netting you really don't want all that designer boilerplate in your main codefile.



  • @Cassidy said:

    Are partials the equivalent of an "include" then?

    No
    @Cassidy said:
    Just being able to split one big class out into separate files?

    You can also separate it in the same file.
    @Cassidy said:
    Can those partials be used in other classes?

    Not sure what you mean by this, the partial class behaves as any normal class. The most common uses I have found is either extending a generated class or hiding complexity



  • Okay... so to summarise:

    • I kinda get an idea of what they do
    • I still don't fully understand what they are
    • I don't code in C# so it's not that important anyway
    • They can be repurposed easily in a complete WTF manner



  • @PedanticCurmudgeon said:

    @Smitty's Fuckwit Colleague said:

    "All subclasses must be partial classes of same class to make coding simpler and eliminate overhead of too many classes."

    So someone who obviously doesn't understand OOP is not only producing code, but designing classes. This is a sure sign that we've made programming too easy. When I'm elected world dictator, I will require all programmers to produce working Haskell code before being allowed to use any other programming language.



    +1

    I use partial classes to add code to the fucked up classes the consultants left in my system. They reimplemented all the basic types, one for int, one for decimal, ect. In order to make them play nice(r) with normal C# code I'm writing casts and I don't want to see all their crappy code. You know, first turning an int into a byte array and then saving it to a MemoryStream. Making you own fucked up decimal implementation takes a lot more code than you would think; that would make it really hard to find my own code if it wasn't in a seperate file.

    But seriously, OP that's a huge wtf; just feel lucky that you have the oppertunity to yeall at your consultants.


  • SockDev

    @Cassidy said:

    Okay... so to summarise:

    • I kinda get an idea of what they do
    • I still don't fully understand what they are
    • I don't code in C# so it's not that important anyway
    • They can be repurposed easily in a complete WTF manner


    Partial classes are simple really - it's a code jigsaw. The compiler takes all the pieces (partial classes) and completes the jigsaw (class).

    The most common use-case for partial classes is to separate generated code from hand-written code, as in WinForms, WPF, WebForms, ASP.NET MVC, Silverlight, WinRT/Metro etc. One partial class file contains the code that supports the form/markup, the other is where you write the code that matters 🙂

     



  • @RaceProUK said:

    The most common use-case for partial classes is to separate generated code from hand-written code, as in WinForms, WPF, WebForms, ASP.NET MVC, Silverlight, WinRT/Metro etc. One partial class file contains the code that supports the form/markup, the other is where you write the code that matters 🙂
     

     That kind of raises the question why these classes are the same instead of, erm, two different classes.


  • SockDev

    @dhromed said:

    @RaceProUK said:
    The most common use-case for partial classes is to separate generated code from hand-written code, as in WinForms, WPF, WebForms, ASP.NET MVC, Silverlight, WinRT/Metro etc. One partial class file contains the code that supports the form/markup, the other is where you write the code that matters 🙂
    That kind of raises the question why these classes are the same instead of, erm, two different classes.

    Good question: why use partial classes? Or, if you prefer, why not use partial classes?



  • @dhromed said:

    @RaceProUK said:
    The most common use-case for partial classes is to separate generated code from hand-written code, as in WinForms, WPF, WebForms, ASP.NET MVC, Silverlight, WinRT/Metro etc. One partial class file contains the code that supports the form/markup, the other is where you write the code that matters 🙂
    That kind of raises the question why these classes are the same instead of, erm, two different classes.
    Because they logically should be the same class. It's split this way so that the tool-generated code from the "Designer" can live in a separate unit (file) from the user-generated code, making it so you don't need to worry about what the tool is doing and so the tool doesn't need to worry about stomping on your code.

    The stuff about simultaneous programmers is a holdover from Visual SourceSafe, where source files could only be checked out for one user at a time. But VSS is almost as bad as Community Server and is TRWTF.



  • Good question: Why use a language that requires so much generated boilerplate? Of, if you prefer, why not use a different language?



    Hrm... I guess these rhetorical questions would have more impact if there was a better language I could point to...



  • @dhromed said:

    @RaceProUK said:
    The most common use-case for partial classes is to separate generated code from hand-written code, as in WinForms, WPF, WebForms, ASP.NET MVC, Silverlight, WinRT/Metro etc. One partial class file contains the code that supports the form/markup, the other is where you write the code that matters 🙂
    That kind of raises the question why these classes are the same instead of, erm, two different classes.

    So if you drag a button into the WinForm, you can refer to it in your code as "Button1". Instead of something like, WindowControls.Button1 or Forms["thiswindowname"].Controls.Button1 or whatever awful solution Java would have come up with.



  • @Xyro said:

    Good question: Why use a language that requires so much generated boilerplate?

    It's boilerplate, which is bad, but it's boilerplate almost 100% hidden from the developer, which is good. In short, if you ever need to open up a .designer.cs file, you're almost certainly doing something wrong. You should dedicate yourself to gnodab.



  • @blakeyrat said:

    So if you drag a button into the WinForm, you can refer to it in your code as "Button1". Instead of something like, WindowControls.Button1 or Forms["thiswindowname"].Controls.Button1 or whatever awful solution Java would have come up with.
     

    I got three answers, and yours is the only one that is clear, concise and practical.



  • @blakeyrat said:

    @Xyro said:
    Good question: Why use a language that requires so much generated boilerplate?

    It's boilerplate, which is bad, but it's boilerplate almost 100% hidden from the developer, which is good. In short, if you ever need to open up a .designer.cs file, you're almost certainly doing something wrong.

     

    On the other hand if you have a perfect means of hiding boilerplate, as a systems designer for .Net you might be tempted to add more and more to it.



  • @dhromed said:

    @blakeyrat said:
    So if you drag a button into the WinForm, you can refer to it in your code as "Button1". Instead of something like, WindowControls.Button1 or Forms["thiswindowname"].Controls.Button1 or whatever awful solution Java would have come up with.
    I got three answers, and yours is the only one that is clear, concise and practical.

    Pretty sure I'm the only developer on this board for whom the word "practical" has any meaning. Thanks.

    It also contained a dig at Java for no reason. Bonus.



  • @dhromed said:

    On the other hand if you have a perfect means of hiding boilerplate, as a systems designer for .Net you might be tempted to add more and more to it.

    I'm sure it's policed by thousands of Tech Luddites who dig into the designer.cs file after adding every single control to the window because they don't trust these new-fangled code generating robot-automatons and would wail like banshees if they saw even a single character that wasn't absolutely necessary.

    Microsoft developer tools are better, but Microsoft developers are still tools. See what I did there? Clever huh?



  • @blakeyrat said:

    @dhromed said:
    @blakeyrat said:
    So if you drag a button into the WinForm, you can refer to it in your code as "Button1". Instead of something like, WindowControls.Button1 or Forms["thiswindowname"].Controls.Button1 or whatever awful solution Java would have come up with.
    I got three answers, and yours is the only one that is clear, concise and practical.

    Pretty sure I'm the only developer on this board for whom the word "practical" has any meaning. Thanks.

    It also contained a dig at Java for no reason. Bonus.



    No, I'm pretty concerned about being practical too.

  • SockDev

    @this_code_sucks said:

    @blakeyrat said:
    @dhromed said:
    @blakeyrat said:
    So if you drag a button into the WinForm, you can refer to it in your code as "Button1". Instead of something like, WindowControls.Button1 or Forms["thiswindowname"].Controls.Button1 or whatever awful solution Java would have come up with.
    I got three answers, and yours is the only one that is clear, concise and practical.

    Pretty sure I'm the only developer on this board for whom the word "practical" has any meaning. Thanks.

    It also contained a dig at Java for no reason. Bonus.



    No, I'm pretty concerned about being practical too.

    Same here.


  • SockDev

    @blakeyrat said:

    @dhromed said:
    On the other hand if you have a perfect means of hiding boilerplate, as a systems designer for .Net you might be tempted to add more and more to it.

    I'm sure it's policed by thousands of Tech Luddites who dig into the designer.cs file after adding every single control to the window because they don't trust these new-fangled code generating robot-automatons and would wail like banshees if they saw even a single character that wasn't absolutely necessary.

    Microsoft developer tools are better, but Microsoft developers are still tools. See what I did there? Clever huh?

    Depends which devs you're talking about. I doubt there's one single tool on any of the compiler teams. On the Silverlight team, however...



  • @blakeyrat said:

    @dhromed said:
    @RaceProUK said:
    The most common use-case for partial classes is to separate generated code from hand-written code, as in WinForms, WPF, WebForms, ASP.NET MVC, Silverlight, WinRT/Metro etc. One partial class file contains the code that supports the form/markup, the other is where you write the code that matters 🙂
    That kind of raises the question why these classes are the same instead of, erm, two different classes.

    So if you drag a button into the WinForm, you can refer to it in your code as "Button1". Instead of something like, WindowControls.Button1 or Forms["thiswindowname"].Controls.Button1 or whatever awful solution Java would have come up with.

     

    Or they could have just done it the sensible way and included a form definition script in a simple DSL, that the compiler embeds as a resource.  Now you don't need to introduce a stupid concept like "partial classes" to the language, you don't need a C# interpreter inside the form designer, and you don't need a new <insert language here> interpreter for the form designer every new .NET language that gets created.  Just put a couple virtual methods in your base component class to handle serialization and deserialization to the DSL, and build the core of the (de)serialization logic one time in the form designer, and you're done.


  • SockDev

    @Mason Wheeler said:

    @blakeyrat said:

    @dhromed said:
    @RaceProUK said:
    The most common use-case for partial classes is to separate generated code from hand-written code, as in WinForms, WPF, WebForms, ASP.NET MVC, Silverlight, WinRT/Metro etc. One partial class file contains the code that supports the form/markup, the other is where you write the code that matters 🙂
    That kind of raises the question why these classes are the same instead of, erm, two different classes.

    So if you drag a button into the WinForm, you can refer to it in your code as "Button1". Instead of something like, WindowControls.Button1 or Forms["thiswindowname"].Controls.Button1 or whatever awful solution Java would have come up with.

     

    Or they could have just done it the sensible way and included a form definition script in a simple DSL, that the compiler embeds as a resource.  Now you don't need to introduce a stupid concept like "partial classes" to the language, you don't need a C# interpreter inside the form designer, and you don't need a new <insert language here> interpreter for the form designer every new .NET language that gets created.  Just put a couple virtual methods in your base component class to handle serialization and deserialization to the DSL, and build the core of the (de)serialization logic one time in the form designer, and you're done.

    The 'DSL form definition script' would still need to be translated into something that the C# code can use - all you've suggested here is exactly what XAML et al are. And it still doesn't remove the usefulness of partial classes.



  • @Mason Wheeler said:

    Or they could have just done it the sensible way and included a form definition script in a simple DSL, that the compiler embeds as a resource.  Now you don't need to introduce a stupid concept like "partial classes" to the language, you don't need a C# interpreter inside the form designer, and you don't need a new <insert language here> interpreter for the form designer every new .NET language that gets created.  Just put a couple virtual methods in your base component class to handle serialization and deserialization to the DSL, and build the core of the (de)serialization logic one time in the form designer, and you're done.

    Good lord. Why add all of that complexity for something with a simple solution like splitting a class across multiple files?



  • @PJH said:

    It appears not.
    It is possible to split the definition of a class or a struct, or an interface over two or more source files. Each source file contains a section of the class definition, and all parts are combined when the application is compiled. There are several situations when splitting a class definition is desirable:

    • When working on large projects, spreading a class over separate files allows multiple programmers to work on it simultaneously.
    • When working with automatically generated source, code can be added to the class without having to recreate the source file. Visual Studio uses this approach when creating Windows Forms, Web Service wrapper code, and so on. You can create code that uses these classes without having to edit the file created by Visual Studio.
    • To split a class definition, use the partial keyword modifier, as shown below:

    I'm not sure about that third bullet point however.
     

    1 - WTF source control Microsoft wants you to use? Source Safe? Programmers are quite capable of working on the same file when they get non-WTF tools.

    2 -  WTF that means: "code can be added to the class without having to recreate the source file"? (And yes, TRWTH is Java's requirement that all the code stays at the class definition. If that phrase means that .Net aleviated it, more power for MS. Anyway, TRWTF is still MSDN.)

     



  • @Mason Wheeler said:

    Or they could have just done it the sensible way and included a form definition script in a simple DSL, that the compiler embeds as a resource.  Now you don't need to introduce a stupid concept like "partial classes" to the language, you don't need a C# interpreter inside the form designer, and you don't need a new <insert language here> interpreter for the form designer every new .NET language that gets created. Just put a couple virtual methods in your base component class to handle serialization and deserialization to the DSL, and build the core of the (de)serialization logic one time in the form designer, and you're done.

    Then turn the crank and snap the plank and boot the marble right down the chute and watch it roll and hit the pole and knock the ball in the rub-a-dub-tub which hits the man into the pan. The trap is set, here comes the net.

    BTW: @Mason Wheeler said:

    and you don't need a new <insert language here> interpreter for the form designer every new .NET language that gets created.

    Is there a requirement that all parts of a partial class are in the same language? I should test that...



  • @boomzilla said:

    @Mason Wheeler said:
    Or they could have just done it the sensible way and included a form definition script in a simple DSL, that the compiler embeds as a resource.  Now you don't need to introduce a stupid concept like "partial classes" to the language, you don't need a C# interpreter inside the form designer, and you don't need a new <insert language here> interpreter for the form designer every new .NET language that gets created.  Just put a couple virtual methods in your base component class to handle serialization and deserialization to the DSL, and build the core of the (de)serialization logic one time in the form designer, and you're done.

    Good lord. Why add all of that complexity for something with a simple solution like splitting a class across multiple files?

     

    1. Because it's not about splitting a class across multiple files, it's about separating the default initial state of a form instantiation (data) from the code of the form's class.  Splitting a class across multiple files is an implementation detail, and it's one that opens up your language to all sorts of new and interesting abuses.  (Such as the original post.)
    2. Because it greatly reduces complexity in other ways:  For example, the form definition language can be much, much simpler than a Turing-complete language, since its only purpose is to describe data in a declarative format, which makes both parsing the code and reading it (when running a diff before checking in, for example) much simpler.
    3. Because it doesn't open a security hole in the form designer. (This is related to the DSL not being Turing-complete.)  What would happen if someone put a call to System.FileSystem.RecursivelyDeleteEntireMyDocumentsFolder() in a form-description partial-class file where no one ever looks?  (I actually don't know.  Do they have a sandbox in there?  If so, how does it determine what's valid and what isn't?)
    4. If the form is defined as data instead of code, then on the program's side you can set callbacks to customize the process.  You can't do that when the form description is hard-coded.
    5. As I mentioned before, you only have to implement this one time, instead of making every language create their own form designer support.  This is particularly important for a multi-language runtime like .NET, and yet they got it wrong.

    And yes, they eventually got it (mostly) right with XAML, except that XAML is not a simple DSL for any value of "simple" that I'm aware of.  Not when people describe it as having "a learning cliff, not a learning curve."



  • @blakeyrat said:

    @Mason Wheeler said:
    Or they could have just done it the sensible way and included a form definition script in a simple DSL, that the compiler embeds as a resource.  Now you don't need to introduce a stupid concept like "partial classes" to the language, you don't need a C# interpreter inside the form designer, and you don't need a new <insert language here> interpreter for the form designer every new .NET language that gets created. Just put a couple virtual methods in your base component class to handle serialization and deserialization to the DSL, and build the core of the (de)serialization logic one time in the form designer, and you're done.

    Then turn the crank and snap the plank and boot the marble right down the chute and watch it roll and hit the pole and knock the ball in the rub-a-dub-tub which hits the man into the pan. The trap is set, here comes the net.

    Wow, that takes me back. I haven't seen that ad (or played the game) since elementary school.  But as I already mentioned, there are a lot of real benefits to doing it that way.  And do you seriously mean to imply that a simple serialization system to a declarative language is overly complex, but needing to put an interpreter for a turing-complete language into your form designer is not?!?

    BTW: @Mason Wheeler said:
    and you don't need a new <insert language here> interpreter for the form designer every new .NET language that gets created.

    Is there a requirement that all parts of a partial class are in the same language? I should test that...

     

    There would have to be, because one single compiler has to build it.  Have you ever seen a way to create an assembly containing code from more than one language?

     



  • @Mason Wheeler said:

    And do you seriously mean to imply that a simple serialization system to a declarative language is overly complex, but needing to put an interpreter for a turing-complete language into your form designer is not?!?

    Yes, because I only give a flying fuck about the end-user experience, not "how much work the CPU does". Because I'm sane. And right now, the end-user experience of the developer using XAML is a fuckload worse than that of the developer using WinForms. So XAML is demonstrably not "better" in any way that matters to me.



  • @Mason Wheeler said:

    Because it's not about splitting a class across multiple files, it's about separating the default initial state of a form instantiation (data) from the code of the form's class.  Splitting a class across multiple files is an implementation detail, and it's one that opens up your language to all sorts of new and interesting abuses.  (Such as the original post.)

    Yes, it was an implementation detail. I don't know if that was the original reason why they created that feature. But it's a reasonable way to implement it. Obviously not your preferred choice, but meh.

    @Mason Wheeler said:

    Because it greatly reduces complexity in other ways:  For example, the form definition language can be much, much simpler than a Turing-complete language, since its only purpose is to describe data in a declarative format, which makes both parsing the code and reading it (when running a diff before checking in, for example) much simpler.

    Now they have to recreate the entire API for creating controls in the DSL. And update it when it changes. Or else people will stop using it because it's crippled.

    @Mason Wheeler said:

    Because it doesn't open a security hole in the form designer. (This is related to the DSL not being Turing-complete.)  What would happen if someone put a call to System.FileSystem.RecursivelyDeleteEntireMyDocumentsFolder() in a form-description partial-class file where no one ever looks?  (I actually don't know.  Do they have a sandbox in there?  If so, how does it determine what's valid and what isn't?)

    We should hide the source code from the developers, too, or they might slip some dumb code in there, too.

    @Mason Wheeler said:

    If the form is defined as data instead of code, then on the program's side you can set callbacks to customize the process.  You can't do that when the form description is hard-coded.

    Er...what? It's part of the class. You can do anything you want with it.

    @Mason Wheeler said:

    As I mentioned before, you only have to implement this one time, instead of making every language create their own form designer support.  This is particularly important for a multi-language runtime like .NET, and yet they got it wrong.

    This is a legitimate thing.

    @Mason Wheeler said:

    And yes, they eventually got it (mostly) right with XAML, except that XAML is not a simple DSL for any value of "simple" that I'm aware of.  Not when people describe it as having "a learning cliff, not a learning curve."

    I've never used XAML, but I've used similar things, and they always seem less convenient to me than putting stuff into code, except that you gain easy portability among languages. And again, I'd say that any "simple" DSL for this purpose will be too simple for many uses, and you end up specifying lots of stuff through code anyways.



  • @blakeyrat said:

    @Mason Wheeler said:
    And do you seriously mean to imply that a simple serialization system to a declarative language is overly complex, but needing to put an interpreter for a turing-complete language into your form designer is not?!?

    Yes, because I only give a flying fuck about the end-user experience, not "how much work the CPU does". Because I'm sane. And right now, the end-user experience of the developer using XAML is a fuckload worse than that of the developer using WinForms. So XAML is demonstrably not "better" in any way that matters to me.

     

    I never said that it was. In fact, if you read what I actually wrote, you'll see that I called XAML overly complicated.  That doesn't mean that the concept is bad; XAML is a very bad implementation of a good idea.  (Surely a fellow programmer should be able to understand that concept.)



  • @Mason Wheeler said:

    I never said that it was. In fact, if you read what I actually wrote, you'll see that I called XAML overly complicated. That doesn't mean that the concept is bad; XAML is a very bad implementation of a good idea. (Surely a fellow programmer should be able to understand that concept.)

    Then show me the good implementation you're raving about.

    Oh wait, let me fucking guess: it doesn't exist, right? I'm going to vote "it doesn't exist." Do I win?



  • @boomzilla said:

    @Mason Wheeler said:
    Because it greatly reduces complexity in other ways:  For example, the form definition language can be much, much simpler than a Turing-complete language, since its only purpose is to describe data in a declarative format, which makes both parsing the code and reading it (when running a diff before checking in, for example) much simpler.

    Now they have to recreate the entire API for creating controls in the DSL. And update it when it changes. Or else people will stop using it because it's crippled.

    Nope.  That's why you set up the basic serialization code in the base component class, which in this case would be implemented in C#.  If it works based on reflection, it should be able to serialize and deserialize 90% of all cases with no additional help.  Any new components that need more tweaking would have to override the methods and add their own specific logic in whatever language they're written in, but any given part of the system only has to be done once, because all .NET languages can communicate with each other through the shared IL ABI.

    @Mason Wheeler said:
    If the form is defined as data instead of code, then on the program's side you can set callbacks to customize the process.  You can't do that when the form description is hard-coded.

    Er...what? It's part of the class. You can do anything you want with it.

    Not if you want it to exhibit different behavior when it's actually running in your program as opposed to being loaded into the form designer.  And not if you want your custom behavior to stay exactly the way you left it.  A file that's created by a code generator is owned by the code generator, and any manual changes are liable to get stomped the next time the code generator runs.



  • @blakeyrat said:

    @Mason Wheeler said:
    I never said that it was. In fact, if you read what I actually wrote, you'll see that I called XAML overly complicated. That doesn't mean that the concept is bad; XAML is a very bad implementation of a good idea. (Surely a fellow programmer should be able to understand that concept.)

    Then show me the good implementation you're raving about.

    Oh wait, let me fucking guess: it doesn't exist, right? I'm going to vote "it doesn't exist." Do I win?

    On the contrary, it exists in Delphi, and they've been using the system successfully since 1995, and making it interoperate successfully with C++ Builder the whole time.  (And considering that .NET was created by former Delphi team members, and that C# 1.0 resembled nothing so much as "Delphi rewritten to look like Java syntax," I'm a bit surprised that they somehow managed to screw up one of Delphi's best features.  Maybe they had to do it wrong to avoid stepping on one of Borland's patents or something. *shrug*)

     



  • Oh fuck you the Delphi shit again. I'm sure Delphi is a brilliant brilliant tool that solved every problem in history ever and brought world peace and the only reason nobody uses it is because we're all ignorant savages and not at all the Occam's razor explanation that it's a shit tool.

    You know if you had asked me like 5-6 years ago whether I thought a programming language could have a "reality distortion field" the same way that Apple products do, I would have said no.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.