[Mono-list] Some Crucial Not Implemented VB Items

[A Rafael D Teixeira]

>From: "JD Conley" <jconley@winfessor.com>
>
>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
>them.
>
>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
...
  End If

>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 
late-bounding).

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!!!

Best regards,

Rafael Teixeira
Brazilian Polymath
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. 
http://messenger.msn.com.br