[Mono-list] Some Crucial Not Implemented VB Items
A Rafael D Teixeira
Wed, 21 Jan 2004 18:32:38 -0200
>From: "JD Conley" <firstname.lastname@example.org>
>There are a few items in VB that are not implemented that, IMHO, would
>make it much more useable. I'm not sure if anyone is really working on
>VB now-a-days, but I would really like to see it improved. VB is the
>most widely used language in the corporate world and a good, free,
>implementation would go a long way. Anyway, here's the items that are
>immediately important for me, but unfortunately I don't have the
>knowledge to dive into the VB class libraries or compiler and implement
>1) Synclock Blocks - System.Threading.Monitor.Enter/Exit is implemented,
>but not the "Synclock Object"/"End Synclock" block. I use this all the
>time and the extra 3 lines of code required to use the Monitor class
>really clutters things up.
Seems to be an easy thing, but never looked at that feature. Please file a
bugzilla for this item, with some testing code, typical of your usage.
>2) IsNothing() Method - The Is keyword is imlpemented so you can do
>"Object Is Nothing" but not this more readable version.
I've implemented in a pair of minutes. Already landed on cvs. But for now
you have to fully qualify it's use, like :
If Information.IsNothing(Expression) Then
>3) Preserve Keyword - It's a pain to have to make temporary copies of
>arrays when you need to change the bounds.
The problem is finding the proper division of labor, between code to be
generated where the redim preserve occurs and what a helper class/method
should do. Besides I'll have to delve in what code compiled with vbc does in
that case so that it can work inside our runtime with our version of the
class library. Please, again add a bugzilla case, for us to track the
implementation of this feature.
Note: Performance-wise "ReDim Preserve" is a bad thing, because it DOES COPY
all your array content into a new one. Avoid it for large arrays, or those
that repeatedly change size.
>I'm really impressed with the runtime and class libraries as a whole, I
>just wish VB.NET support was at the same level as C#. I've got a lot of
>large applications written in VB.NET that I'd like to run on Mono, but
>it's just not feasible to port them to C# or work around everything
>that's not implemented.
I must tell you that other issues presently have higher priority, like
tweeking the name-resolving logic to expose "VB modules" members as global
(unqualified) names (so that can use IsNothing() unqualified). Also
currently most of code-generation works C#-ish (just like if "option strict
on" is always set) because we resolve all names at compile-time (no
Anyway, if you can't feel like delving inside our code, just experimenting
with it and reporting issues (via bugzilla) will help us a lot.
Thank you for the interest!!!
Mono Hacker since 16 Jul 2001
MonoBrasil Founding Member - Membro Fundador do MonoBrasil
English Blog: http://monoblog.blogspot.com/
Brazilian Portuguese Blog: http://monoblog.weblogger.terra.com.br/
MSN Messenger: instale grátis e converse com seus amigos.