[Mono-dev] [PATCH] Implement support for compiled regular expressions in profile 1.x

Kornél Pál kornelpal at gmail.com
Fri Apr 3 18:58:54 EDT 2009


I think that using public fields instead of private ones costs no work.
Parts of this patch related to dynamic assemblies are just a few lines 
that is complete and needs no maintenace. I didn't have to change a 
single character in the code generator so the part that really needs 
maintenance is not affected by this solution.

On the other hand maintaining implementations using generic and 
non-generic hashtables needs maintenance.

Most of the things is about introducing non-generic Hashtables and 
getting rid of GetEvalMethod and CreateEvalMethod methods and making 
EmitEvalMethodBody return boolean instead of the single DynamicMethod 
instance ever created in the flow or null. These latter things help 
maintaining code but most likely won't be accepted either because are 
not required if we don't want support without DynamicMethods.

Anyway I'm not going to push this patch, I just implemented this because 
this was very straightforward to implement and this solution (at least 
to me) seems to be very straightforward.

Kornél

Rodrigo Kumpera wrote:
> Kornél,
> 
> Using dynamic assemblies will increase the maintenance burden for no 
> good advantage. It should be done with dynamic methods, if at all.
> 
> 
> 
> 2009/4/3 Kornél Pál <kornelpal at gmail.com <mailto:kornelpal at gmail.com>>
> 
>     Hi,
> 
>     The runtime has support for generic types in profile 1.0 as well,
>     OnDeserializedAttribute could also be used, just like new case
>     insensitive and culture invariant string operations/comparison,
>     static classes could be supported by profile 1.0 C# compiler because
>     no runtime support is needed, and this is just some examples of
>     possible 2.0 suff for internal use in 1.0 class library.
> 
>     As far as I know none of them or any other 2.0 features are used
>     outside of mscorlib.dll.
> 
>     Also note that this is a complete patch including replacing the
>     generic Dictionaries with non-generic Hashtables.
> 
>     Attached a more recent version of the patch with some minor updates.
> 
>     Kornél
> 
>     Rodrigo Kumpera wrote:
> 
>         I think a better approach instead of using dynamic assemblies is
>         to use dynamic methods on 1.0 as well.
>         They can be exposed as internal stuff from mscorlib to System
>         and most of the work will replacing the generic
>         stuff.
> 
>         2009/4/2 Kornél Pál <kornelpal at gmail.com
>         <mailto:kornelpal at gmail.com> <mailto:kornelpal at gmail.com
>         <mailto:kornelpal at gmail.com>>>
> 
> 
>            Hi,
> 
>            Because of the restrictions of 1.x I modified visibility so I
>         also would
>            like to set skipVisibility = false in DynamicMethod
>         constructor (not
>            included in the patch) to avoid 1.x only bugs because of this.
> 
>            Kornél
> 
>            Kornél Pál wrote:
>             > Hi,
>             >
>             > I've implement support for compiled regular expressions in
>            profile 1.x
>             > using dynamic assemblies.
>             >
>             > I also have cleaned up the code by removing GetEvalMethod and
>             > CreateEvalMethod methods and moving their functionality to
>             > GetMachineFactory.
>             >
>             > I also modified the signature of EmitEvalMethodBody and
>         replaced
>            generic
>             > dictionaries with hashtables in profile 1.x that results
>         in a larger
>             > patch but I haven't modify the actual code generator.
>             >
>             > I also had to modify some visibility levels to pass
>         runtime type
>            checks.
>             >
>             > Please review the attached patch.
>             >
>             > Kornél
>             >
>            _______________________________________________
>            Mono-devel-list mailing list
>            Mono-devel-list at lists.ximian.com


More information about the Mono-devel-list mailing list