[Mono-list] methods without arguments do not need parentheses
It's also VB.Net code style. I personally would never write a parenthesis for such a function or procedure call. Also that allows you to easily change from a function to property without other code changes neccesary. A.Nahr P.S. I'm not 100% sure but the text does probably mean "method CALLS without arguments do not need parentheses", otherwise(method declarations) I'm of your opinion. I'm not sure this " methods without arguments do not need parentheses" is a good thing.It's VB6 style coding, VB.NET doesn't normally allow this.regards,Timothy.
[Mono-list] methods without arguments do not need parentheses
Hi, first of all IMHO parentheses do DECREASE general code readibility in that case. Look at the following lines and judge for yourself: DisplaySize = Me.GetMinimumSize ().ToPointF ().X.ToString ().Length DisplaySize = Me.GetMinimumSize.ToPointF.X.ToString.Length In 99.9% of all possibilities it doesn't matter if I'm calling an _expression_ or statement (and you don't need and want to know). And don't forget that you don't use parenthesis for properties either (which are internally just method calls). There is another major point. If we remove that about 95% or all VB.Net code that exists on the net will not compile with MBas (just check the user contriubutions at gotdotnet). That means mbas will not be a superset of VB.Net as is says but a subset. You are correct that they generally don't hurt. They don't hurt if someone WANTS to use them, and they can (and should) use them, but if somebody doesn't want to, then there is no reason to FORCE him to do. Thats the main aspect of VB.Net and one of the main differences to C#: In VB.Net there is always more than one way to do something. And while this is the curse of VB it's also it's biggest advantage. If you really like the compiler to check that then add a compiler option that you can turn on (and is off by default) and that checks for empty parenthesis. Andreas Nahr Original: No, it's no good thing at all, IMO. Parentheses increase the readabilityof code with no hurt at all, by simply distinguishing between an_expression_ and a statement.
[Mono-list] RE: unmanaged type limitations -- no unmanaged arrays?
IMHO you can do such things in VB.Net (marshalling fixed sized strings). I'm not sure if there is a way to do this in C# (and as far as I can remember there isn't a way). However you might look at how this is done in VB.Net and then either use the same technique if possible in C#. Andreas P.S. I never tried this with Mono, so I don't know if passing fixed size strings is already supported in MonoBasic
[Mono-list] Method Attributes
On Sat, 2003-08-16 at 15:17, Hamza Karamali wrote:> Hi,> > If I attach a custom attribute called "myAttribute" to a certain method,> how can I check in Mono (while the method is being compiled) whether a> method has this attribute? Is there a function that will search the> metadata for the attribute if I pass it the name of the attribute? If> not, how would I go about doing this?> Just call: TypeDescriptor.GetAttributes(TheObjectThatShouldBeTested) and check for the attribute in the result AttributeCollection (Please note that this function may not be completed 100% in Mono right now) Andreas
[Mono-list] Re: [Mono-devel-list] C#isms in CodeDom core and other bugs - willing to fix
In Text
> I'm working on a CodeDom provider for a language that happens to look an
> awful lot like C#[1].
I've done the one for VB, so If you have any problems I might be able to
help.
> I thought it would be sufficient to start with Mono's
> CSharpCodeGenerator and go through it in detail, changing each construct
> to the equivalent in Ja^H^Hthe language I'm dealing with. This turns out
> to actually not be sufficient, though, because in several places
> CSharpCodeGenerator simply inherits an implementation from CodeGenerator
> which gives C#-specific behavior. Examples of this behavior are
> OutputTypeAttributes() and OutputMemberAccessModifier(), both of which
> are non-abstract in CodeGenerator and give pure C# output.
>
> This seems like an incredibly bad idea that defeats the purpose of
> having a language-independent API. I recognize that there are other good
> reasons why the CodeDom API sucks (I've already compiled a half dozen
> items in my wishlist of API features) but this seems to me like
> implementation suckage, not API suckage.
This does not seem to be a big problem to me. It may not be a perfectly
clean approach, but it certainly is rather efficient. And as MOST people
will probably just use CodeDom and not implement their own Provider - so
they probably don't care about the 'cleaness' of the implementation.
> It may be that this behavior is required to be fully compatible with a
> sucky MS implementation. If that's the case, there should be a prominent
> comment in the source of CodeGenerator explaining this. I'd also be
> tempted to duplicate the methods in CSharpCodeGenerator even though
> that's technically redundant, because it's closer to the correct
> separation of concerns between the two classes. If not, there should at
For me it just seems you define the 'concern' of CodeGenerator MUCH
different than I do. IMHO this is just a helper class that eleminates
unneccessary code duplication. If you want to start from scratch - No
problem. Just implement the ICodeGenerator interface in whatever class you
like. There is NO NEED to use this class to do code generation.
Also I don't know what your whole C# thingy is: MS probably choose to
implement methods which seemed as they may be used by several different
languages to avoid code duplication. If you look at something like:
protected virtual void OutputTypeNamePair (CodeTypeReference type,
string name)
{
OutputType (type);
output.Write (' ');
output.Write (name);
}
This will work for several languages. E.g. C#, J#, Managed C++ and others -
even Java. However it will obviously not work for VB.Net. But IMHO it is a
good thing to avoid TRIPPLE code duplication within what gets shipped as ONE
framework - even if it is a little bit less clean because you have to
override that method for Visual Basic.
Also all of this 'mess' is not even visible to the outside world, its all
protected.
> least be a large comment at the top of CSharpCodeGenerator documenting
> which methods it inherits from CodeGenerator that are C#-specific.
Why document if you can easily see which are inherited?
CSharpCodeGenerator.cs is no template file for other Code Generation Engines
but the implementation of CodeGenerator for C#
> If I produce a patch to this effect, would it be accepted? Which
> approach should I take?
*I* definatelly wouldn't like it. I've done quite some work on CodeDom
(mostly VB stuff - e.g. VBCodeGenerator.cs). I also doubt that others will
be happy if you just duplicate the code to make *the implementation* (not
even a public accessible something) more 'stylish'.
>From the point of a user (myself) of the CodeDomain namespace:
I know that lots of people aren't happy with it. At first you think that you
found the coolest thing ever, but then you pretty fast realize that it can't
be used for anything more that simple creation of stubs or super-small and
trivial applications.
In fact if you think a little bit about the whole problem you realize pretty
fast that it is impossible to have something like CodeDomain for a language
neutral framework because the maximum common ground you can find between all
languages is the IL itself. And then you can as well use Reflection emit.
The only way this would work was if every language would add its own laguage
elements to CodeDom, however this would defeat the whole purpose of it.
The thing that stroke me most after thinking that I just found the coolest
thing ever with CodeDom was when I realized that CodeParser is not
implemented at all in the .Net Framework ;)
I first saw CodeDom and thought it should be possible to create a universal
language converter in just a few minutes ;)
> If I'm correct about these behaviors being bugs, should I produce
> patches for them?
Absolutely. Glad to see you on board!
>
> [1] Can you imagine what that language could *possibly* be? ;)
Let me have a guess. Starts with 'J' and ends with 'ava'
___
Re: [Mono-list] [Mono-dev] System.CodeDom.Compiler and Debugging
Hi, akaik there is no integrated debugger support in any of the class libraries. Neither through CodeDom, nor through Reflection.Emit. You should be able to attach an external debugger (Mono or .Net) however this is surely a non-trivial task. -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Vikas N Kumar Gesendet: Freitag, 26. Oktober 2007 17:35 An: [EMAIL PROTECTED]; mono-list@lists.ximian.com Betreff: [Mono-dev] System.CodeDom.Compiler and Debugging Hi I have written an application in which I write code inside a text box, click a button that compiles the code using System.CodeDom.Compiler, loads the code into memory and executes it. This works fine until there is an error in the code that was written in the text box, and I am not able to debug that using either Visual Studio or Mono's debugger. Do you have any suggestions ? Are there classes that .NET gives that I can use in my application itself so that the application itself can debug the code in the textbox at runtime ? System.Diagnostics doesn't seem to do that though. Is it possible for me to embed Mono's debugger inside an application and get the debugger to debug the code that is typed in at runtime ? Any help will be appreciated. Thanks and Regards Vikas Kumar -- http://www.vikaskumar.org/ ___ Mono-devel-list mailing list [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
