[69318 Closed] Nullable guid type "changing" when moved to separate assembly

I generated code using slsvcutil from a wcf service. It generated this snippet:

Guardian.EditObservation.DataContracts.PersonBase = public partial class(System.Object)
private 
    var IDField: System.Nullable<System.Guid>;
    method get_ID: System.Nullable<System.Guid>;
    method set_ID(value: System.Nullable<System.Guid>);
public 
    [System.Runtime.Serialization.DataMemberAttribute]
    property ID: System.Nullable<System.Guid> read get_ID write set_ID;

Then I added this in another file:

  PersonBase = public partial class( Object )
     private
         etc.

All of that was in one assembly. In that same assembly I had this code:

type
      PersonBaseList      = List<PersonBase>;
      PersonList              = PersonBaseList;

      for each p  in PersonList do begin
         if p.ID.Equals( value ) then begin
            var found : Boolean := false;
            for each observer : PersonBase in ObserverChoicesList do begin
               if p.ID.Value = observer.ID.Value then begin
                  found := true;
                  break;
                  end;
               end;...

Note the p.ID.Value and Observer.ID.Value.

Then I had to refactor. So I made a new assembly that included the generated code and the additional partial class definitions.

Then I made the original assembly reference this new one.

Now, there are a couple of problems. First, the type doesn’t seem to be properly inferred when I put my cursor over the p. It just says it is an object. If I add the type of p in the for each as:

      for each p : PersonBase in PersonList do begin

Then the debugger shows the right class. The second problem is that it says I can’t use Value anymore. Not sure why it was required before and now it isn’t.

And later in the code I was doing:

   method PersonComparer.Compare( x: PersonBase; y: PersonBase ): Int32;
      begin
      if ( x = nil ) and ( y = nil ) then exit 0;

      if x = nil then exit -1;

      if y = nil then exit +1;

      if ( x.ID.Value = Guid.Empty ) and
         ( y.ID.Value = Guid.Empty ) then exit 0;

      if x.ID.GetValueOrDefault = Guid.Empty then exit -1;  

But now it says that Value can’t be used and

error PE223: "System.Guid" does not contain a definition for "GetValueOrDefault" in expression "x.ID.Value.GetValueOrDefault"

First it shouldn’t be a system.guid, it should be a nullable system.guid. And second, why can’t I use the GetValueOrDefault anymore.

I suspect all of this has to do with the special way Oxygene treats system.nullable<system.guid>, but I didn’t expect things to change just because I refactored the code to another assembly.

Can someone explain what is going on here?

Thanks, logged as bugs://69318: Nullable guid type “changing” when moved to separate assembly

I want to say when I first started using Oxygene I had a similar problem come up. I think someone told me it was generated as <system.nullable><system.guid> rather than nullable guid so that other languages could use it.

That is probably good. I guess maybe a warning would have helped if that is possible. And maybe something in the elements wiki about this situation would have helped.

Thanks.

Yeah. The issue is that inside the assembly there’s a distinct type nullable Integer and &nullable<Integer>, but once emitted that info is gone. Since a year or so we have a place where we can store extra metadata where we can put this so the bug logged is to store info needed to create distinct types.

I’m having to still use the Delphi Prism version at the moment, fwiw. I’m not sure I WANT to always have the type that was generated by the service. I was more wondering why the type changed. Seems like there should be a warning or documentation or something. I prefer the nullable guid type. It would be nice if I could tell slsvcutil to NOT generate a nullable.

(I think I’ve said that right)

Yeah we considered that, but the code one of the generator generates presumes .Value and .ValueOrDefault() exist and calls them, so we couldn’t just emit that.

bugs://69318 got closed as fixed for release Bradbury Class