TOPIC:

I tried in XIDE to use Dynamic, but couldn't get it going.

The error I get is:
error XS1980: Cannot define a class or member that utilizes 'dynamic' because the compiler required type 'System.Runtime.CompilerServices.DynamicAttribute' cannot be found. Are you missing a reference?

This might be due to the bug Microsoft introduced that the target must be set to 4.5.1 at first, after which you can switch back to e.g. 4.6.2. In VS2015 this did the trick.

Note: after this, a reference to Microsoft.CSharp.dll is needed, to fix the compiler error Missing compiler required member 'Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo.Create'.

However, in Xide I can't find where I can set the target location, other to v2.0 and v4.0

Am I looking in the wrong places?

Regards,
Otto

Hi Otto!

I tried this also in c# and I got the same error! By trial and error, realized that you need to also add a reference to System.Core (in addition to Microsoft.CSharp). After doing that, it should work ok also in x#. Guess we should trap this situation and make the compiler report a better error message.

In XIDE, you don't need to set target .Net framework etc. Only time you might need to worry about this is if you must compile against .Net 2.0 only, but I think probably nobody needs to do this anymore..

Chris

Chris wrote: you need to also add a reference to System.Core (in addition to Microsoft.CSharp). After doing that, it should work ok also in x#.Chris

pmfji, just had a look with a "Basic x# app" and i get "Core does not exist in Namespace System" - after realizing for the x-th time, that reference is not using <g>, peeked into references, added reference to System.Core and Microsoft.CSharp. Trying to run MS sample:
static void Main(string[] args)
{
dynamic dyn = 1;
object obj = 1;

// Rest the mouse pointer over dyn and obj to see their
// types at compile time.
System.Console.WriteLine(dyn.GetType());
System.Console.WriteLine(obj.GetType());
}

i fail at the first line, how to define the "dyn" var. Unfortunately the "Dynamic" page of the help still has a "enter topic text", so i'm a bit at a loss..

BTW, "Dynamic" - and that after so many years of "you are dead meat, man, not using strong typed bla bla...."

Hi Karl,

Probably you are (accidentally) using an older version of the c# compiler. Please go to Preferences/Compiler and set the c# option to the latest c# compiler executable. I think it should be

C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe

But why testing this with c#, instead of x#?

Chris

Chris,
indeed, pointed to net2.0 version, changed that.
But didn't want to test with c#, took only the sample from MS site, translated to:
USING Microsoft.CSharp
USING System.Dynamic
FUNCTION Start( ) AS VOID
System.Console.WriteLine("Hello x#!")

// dyn := 1 AS DynamicObject ??? How to "declare" the var?
// should i "var dyn := 1"
LOCAL obj :=1 AS OBJECT

// Rest the mouse pointer over dyn and obj to see their
// types at compile time.
System.Console.WriteLine(dyn.GetType())
System.Console.WriteLine(obj.GetType())

dyn := dyn + 3
obj := obj + 3
RETURN

Sorry for confusion

Hi Karl,

That should be just

LOCAL dyn AS Dynamic // or System.Dynamic

It's very similar to having

LOCAL dyn AS USUAL

and you use it more or less the same way as you would with a USUAL.

And yes of course I hear your comment about strong typing and I mostly agree, although there are cases where the dynamic type can be very handy, same as USUAL can be handy in some cases in VO.

Chris

Hi Karl, hi Chris,

I have a base class for MVVM like this

public abstract class ExpandoBase inherit DynamicObject implements INotifyPropertyChanged

and that works very well.

I can publish this class in the Pearls group.

Wolfgang

Chris wrote: Hi Karl,

That should be just

LOCAL dyn AS Dynamic // or System.Dynamic
It's very similar to having
LOCAL dyn AS USUAL

and you use it more or less the same way as you would with a USUAL.

And yes of course I hear your comment about strong typing and I mostly agree, although there are cases where the dynamic type can be very handy, same as USUAL can be handy in some cases in VO.

Chris

Dynamic works, System.Dynamic does NOT - "error XS0118: 'System . Dynamic' is a namespace but is used like a type".
My Dyn (or usual) remark was more aimed at the evangelists of progress

Hi Karl,

Oops, sorry!! Yes, there's no "Dynamic" type really, under the hood it's actually declared as System.Object and the rest is done by compiler trickery. I think I should make xide treat "dynamic" as a keyword, will do that for the next ver.

Chris

Hi Wolfgang,

Yes of course!! It's exactly for stuff like that that the pearls section was introduced.

Chris

Hi Chris,

done! I hope this class helps someone. For me it saves a LOT of code and solves the problem to write tons of properties for varying select statement results.

Wolfgang

Wolfgang,

You don't care that DYNAMIC costs you a lot of performance? And you're missing a lot of compiletime typechecking (as you mentioned).

Otto

Hi Otto,

yes, of course I know that. But compared with the time that is needed to read from a database that is ok.
And for compile time checks: very often the contents of a select statement are different, depending on what a user can see/modify or what a user has selected as columns in a grid - so it would be problematic to have hard coded properties that are not related to any column in the select result.

In VO, my DBServer classes most of the time are only the class declaration and a few access variables for virtual/computed fields, and saving a LOT of code, thus making my application smaller and easier to maintain (other than saving to write a lot of redundant code) is worth the missing compile time checks.

Of course, such choices have to be taken comparing the pro's and con's in depth.

For me the advantages of dynamic objects are bigger than the disadvantages.... But for others, this could be the inverse.

Wolfgang

Otto wrote: Wolfgang,

You don't care that DYNAMIC costs you a lot of performance? And you're missing a lot of compiletime typechecking (as you mentioned).

Otto

Otto, nothing against typechecking, we sure all agree that can and is a help. But performance? Yes, you loose - but what the heck? There are usecases, where something is complex and eats lots of data, so the question, will it need 5min or 30sec to return is relevant. But IMHO there's tons of situations where the slow call succeeds in 0.02 secs - and here i couldn't care less, that i miss some milli-secs