It makes everything simpler!
-
@Mason Wheeler said:
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.
Thanks for elaborating on how this is worse than having the definition in native source code (for the end developer, not the tool developer).
@Mason Wheeler said:
@boomzilla said:
@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.You're either being deliberately stupid or you've forgotten that the class for the form isn't contained just in the auto-generated file.
As to getting stomped, well, if the generator is open when you do the edit, then, yeah, expect to be stomped. Otherwise, manual edits get picked up the next time you open it. It's no different than tweaking the DSL in an editor other than the designer tool.
-
@boomzilla said:
@Mason Wheeler said:
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.
Thanks for elaborating on how this is worse than having the definition in native source code (for the end developer, not the tool developer).
OK, what am I missing? What are the disadvantages here?
@Mason Wheeler said:
@boomzilla said:
@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.You're either being deliberately stupid or you've forgotten that the class for the form isn't contained just in the auto-generated file.
Not at all. But the part of the code in question--the code for building the contents of the form--is contained just in the auto-genereted file. And unless the method that builds the contents of the form contains a parameter for a callback (which it doesn't) and code at various points to execute the callback (which it doesn't), there's no way to hook into it as it runs. And the customizations don't have to be confined to a single class; what if you want to customize every instance of a certain control throughout your program in a specific way every time a form containing it is loaded? That's a lot of code duplication... or you could just put one hook into the central deserializer. (If you had one.)
As to getting stomped, well, if the generator is open when you do the edit, then, yeah, expect to be stomped. Otherwise, manual edits get picked up the next time you open it. It's no different than tweaking the DSL in an editor other than the designer tool.
It's not the getting picked up so much as the saving again. If you write anything in there that the form designer doesn't know how to write back out, it might get picked up but it won't be persisted the next time you save it.
-
@blakeyrat said:
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.
An Occam's Razor explanation has to fit the facts. If it were no good, we wouldn't have seen:
- tons of highly useful software built in it, including Microsoft's most valuable acquisition ever
- Microsoft blatantly using its design as the basis for .NET. (They may have built their entire company on ripping off other people's work, but they only ever rip off the best!)
- millions of developers continuing to use it and be productive in it even today, with the community actually growing even while ignorant people think it's dying
There are three actual reasons more people don't use it today. First, because there was a serious brain drain at Borland a few years ago when Microsoft poached a bunch of the team--including Anders Hejlsberg, the principal architect--to create .NET for them. Second, because Microsoft has a marketing budget larger than Borland's entire operating budget, and they're very good at using it. And third, because after all this happened, the guys in charge of Borland totally lost their focus and started trying to promote non-development tools over development tools, and even actively sabotaging work on Delphi and other programming tools for a while.
Of course, they ended up selling off the "useless" programming tools to a company that actually cared about them, and running what was left of the company into the ground. So today, Borland is dead and Delphi is thriving. Just because you don't know about the history involved doesn't mean anything about the product itself.
-
@Mason Wheeler said:
@boomzilla said:
@Mason Wheeler said:
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.
Thanks for elaborating on how this is worse than having the definition in native source code (for the end developer, not the tool developer).
OK, what am I missing? What are the disadvantages here?Based on your description, it sounds more complicated to get everything set up to do things with your controls, as opposed to having the control available as a private member of your class.
@Mason Wheeler said:
But the part of the code in question--the code for building the contents of the form--is contained just in the auto-genereted file. And unless the method that builds the contents of the form contains a parameter for a callback (which it doesn't) and code at various points to execute the callback (which it doesn't), there's no way to hook into it as it runs. And the customizations don't have to be confined to a single class; what if you want to customize every instance of a certain control throughout your program in a specific way every time a form containing it is loaded? That's a lot of code duplication... or you could just put one hook into the central deserializer. (If you had one.)
I suppose the devil is in the details, but this doesn't sound like anything that couldn't be handled by subclassing. As is often the case, solving the same problem in different paradigms requires doing things...differently.
@Mason Wheeler said:
If you write anything in there that the form designer doesn't know how to write back out, it might get picked up but it won't be persisted the next time you save it.
Yes, so just don't do that. Keep that stuff separate. I'd also add that you shouldn't ask the C# compiler to compile SQL queries, because that won't work either.
-
@blakeyrat said:
Is there a requirement that all parts of a partial class are in the same language? I should test that...
My guess is that you can't do that.
@Mason Wheeler said:Have you ever seen a way to create an assembly containing code from more than one language?
That is doable in Net, you can even compile code while you compile code
-
@serguey123 said:
@blakeyrat said:
Is there a requirement that all parts of a partial class are in the same language? I should test that...
My guess is that you can't do that. @Mason Wheeler said:Have you ever seen a way to create an assembly containing code from more than one language?
That is doable in Net, you can even compile code while you compile code[Insert obligatory yo dawg meme here]
OK, having gotten that out of the way, how is that done?
-
@serguey123 said:
@Mason Wheeler said:
Have you ever seen a way to create an assembly containing code from more than one language?
That is doable in Net.The way it works is that the language compilers emit MSIL code (CLR assembly code), and then the assembler turns those into actual assemblies / executables.
-
@Mason Wheeler said:
OK, having gotten that out of the way, how is that done?
The compiler is an Object, like everything else, you only need to create an instance from the language you want and feed the code to it.
-
@serguey123 said:
@Mason Wheeler said:
OK, having gotten that out of the way, how is that done?
The compiler is an Object, like everything else, you only need to create an instance from the language you want and feed the code to it.Generating and Compiling Source Code from a CodeDOM Graph - .NET Framework
Generate and compile source code from a CodeDOM graph in .NET. Use a CodeDOM code provider to generate source code and compile assemblies.
So you can write a program that compiles itself :)
Also, keep an eye out for Roslyn - it exposes the C# and VB.NET compilers as services.
-
@RaceProUK said:
@serguey123 said:
@Mason Wheeler said:
OK, having gotten that out of the way, how is that done?
The compiler is an Object, like everything else, you only need to create an instance from the language you want and feed the code to it.
Generate and compile source code from a CodeDOM graph in .NET. Use a CodeDOM code provider to generate source code and compile assemblies.
So you can write a program that compiles itself :)
Also, keep an eye out for Roslyn - it exposes the C# and VB.NET compilers as services.
So they're essentially building EVAL into C# and VB? Lovely.
-
@blakeyrat said:
Is there a requirement that all parts of a partial class are in the same language? I should test that...
I bet there's an implied one. A while back I was trying to create a single assembly with some VB and some C# code, just to see if I could. You have to compile all your source separately into two .netmodules, one for each language, and then use the assembly linker to produce an assembly dll that is basically just a manifest and reference to the .netmodules, and then you have to distribute all three files--there doesn't seem to be a way to combine it all down into one assembly dll.
Given that you'd have to compile your partial classes with different compilers and produce multiple partial output files I would guess that you can't do it.
-
@serguey123 said:
That is doable in Net, you can even compile code while you compile code
If you can figure out how to do that without creating a multimodule assembly I'd like to know.
-
@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.
Clearly it's different than not using classes at all - you can make as many instances of the god class as you want!
What program doesn't deserve its own pantheon?
-
@Mason Wheeler said:
@boomzilla said:
... which is why the form-building information is in one code file and the custom behavior gets put in a second, separate code file. Which is exactly what both solutions do, except .NET's solution uses only one language instead of two.@Mason Wheeler said:
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.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.
And yes, you can make it exhibit different behavior at design time than it does at run time, although why the hell you would want to do such a thing is completely anathema to me. Have your code check the DesignMode property.
-
@Mason Wheeler said:
So they're essentially building EVAL into C# and VB? Lovely.
Yeah, kind of, of course this is not a new feature, it has been available for a while. There are basically two ways you can use this, either execute code from another language in your project or produce a full fledged compiled file (a dll, an exe, etc) depending on how you do it.
@FrostCat said:If you can figure out how to do that without creating a multimodule assembly I'd like to kno
Did you read the links? I guess most people are just familiar with the "feature" that allows you to use both vb.net files and c# files for a .Net solution or something like that. What I'm talking about is more in line with LINQ, a code provider, hmmm, maybe I should make a mock up?@boomzilla said:
he way it works is that the language compilers emit MSIL code (CLR assembly code), and then the assembler turns those into actual assemblies / executables.
You can also produce native code instead of MSIL but don't tell people that ;) (of course you still need .Net and there are some other caveats)
-
@Mason Wheeler said:
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.
You're smoking crack, I swear you are on drugs. You have a problem with partial classes but you don't have a problem with reflection???? I'm not even going to mention that for everytime I've done something useful with reflection, there was another time where I wish it was never put in .Net. How can you possibly think that storing things in this was is simpler or more elgant than just putting them in the fucking class. Add to that, partial classes give me intellisense! Just when I run into someone who I could swear is the most wrong someone will ever be, I run in to something worse...
There's no way you write C# for a living...
No wonder blakey things he's the on practical person on this forum
-
@this_code_sucks said:
No wonder blakey things he's the on practical person on this forum.
And you can tell he's correct by how often his idea of how to respond to a WTF is to quit his job.
-
@boomzilla said:
@this_code_sucks said:
No wonder blakey things he's the on practical person on this forum.
And you can tell he's correct by how often his idea of how to respond to a WTF is to quit his job.
:D hahaha
I was just thinking about that.
-
@serguey123 said:
@boomzilla said:
he way it works is that the language compilers emit MSIL code (CLR assembly code), and then the assembler turns those into actual assemblies / executables.
You can also produce native code instead of MSIL but don't tell people that ;) (of course you still need .Net and there are some other caveats)Yes you can produce native code, but the way the toolchain is structured, it always goes via MSIL. That way, when a new .NET language is created, all they need is a language-to-MSIL compiler and presto! the language can target desktop Windows, WinRT, WinPhone, XBox 360, Silverlight, et al. Or say there's a new platform, so you make a new MSIL-to-native compiler/JITter and presto! people can use C#, VB.NET, F#, et al on that new platform.
-
@this_code_sucks said:
You have a problem with partial classes but you don't have a problem with reflection???? I'm not even going to mention that for everytime I've done something useful with reflection, there was another time where I wish it was never put in .Net.
Sure, reflection can be abused. But there are good uses for it as well, the two classic ones are binding and serialization.
Add to that, partial classes give me intellisense!
Umm... yes they do, but what does that have to do with anything?
There's no way you write C# for a living...
No, I write Delphi for a living, and the system I described works beautifully there, and has for more than 17 years now, without needing to introduce stupid crap like partial classes into the language.
-
@Mason Wheeler said:
Sure, reflection can be abused. But there are good uses for it as well, the two classic ones are binding and serialization.
And you don't think the samething could be said for partial classes? I guess the difference here is you've used reflection but not partial classes.
@Mason Wheeler said:
Add to that, partial classes give me intellisense!
Umm... yes they do, but what does that have to do with anything?
The system you propsed doesn't give me intellisense so I'd have to remember what I called everything and wouldn't know if I was wrong until runtime.
-
@this_code_sucks said:
@Mason Wheeler said:
Sure, reflection can be abused. But there are good uses for it as well, the two classic ones are binding and serialization.
And you don't think the samething could be said for partial classes? I guess the difference here is you've used reflection but not partial classes.
The difference is that I've never actually come across a good use for partial classes, and the concept always reminds me of some of the worst parts of C++.
@this_code_sucks said:
@Mason Wheeler said:
The system you propsed doesn't give me intellisense so I'd have to remember what I called everything and wouldn't know if I was wrong until runtime.Add to that, partial classes give me intellisense!
Umm... yes they do, but what does that have to do with anything?
The system I proposed is run by the form designer. It uses reflection to get property names and types, so you're not actually missing out on anything that intellisense would provide. If you're trying to manually edit DFM (Delphi Form language) code, you're probably doing something wrong. If you're manually editing it and you don't know the name of the properties you're looking for, you're definitely doing something wrong.
