[fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Anthony Walter]

Thanks for replying. I'd like to chime in with a few thoughts..

I believe manged types beyond string, dynamic array, and interface as
important. In my use case worked around the problem by using records with
private interface as I already mentioned. This solution is less than
optimal as it requires defining 3 types when 1 would do. Also, stakc based
types like record and object are useful because they don't require dynamic
allocation, but have some serious drawback because they do not support
forward declaration.

Consider this situation I am currently working though. I have script
context, object, and value types. both objects and values need to know
about their context, and both value and objects need to know about each
other.

function JSValue.IsObject: Boolean;
function JSValue.ToObject: JSObject;

-and -

procedure JSObject.SetProperty(const Name: string; Value: JSValue);
function JSObject.GetProperty(const Name: string): JSValue;

In this design a value can contain and object, and an object can have
properties that are values. When using records to represent JSValue and
JSObject, this design is simply not possible, because you cannot forward
declare a record.

To work around this using classes (which can be forward declared)  without
a management instead of records is more than cumbersome because of the need
to track all intermediate busy data and manually free each one.

Interfaces by themselves aren't optimal either because you cannot define
conversions or operators on them.

Consider this:

  JSString = record
  ...
  public
    class operator Implicit(const S: string): JSString;
    class operator Implicit(S: JSString): string;
    class operator Equal(A, B: JSString) : Boolean;
    class operator Equal(A: JSString; const B: string) : Boolean;
    property Length: Integer read GetLength;
  end;

- or -

  JSContext = record
  ...
  public
    class operator Implicit(C: JSContext): JSContextRef;
  end;

If I were to use interfaces exclusively, it would be more cumbersome to
work with the JSC API, as it requires ObjectRef types for everything,
including strings. I would have to call methods to convert to, and a
separate set of method to convert from. Where as with records, objects, and
classes, you can write implicit conversions when no data loss takes places,
but types are converted implicitly, removing a lot of needless code
complexity.

In short, because you cannot forward declare record or object types,
because you would to free classes manually in many places, and because
interface types cannot convert to intrinsic types like string or pointer,
managed types for classes is the best solution in this use case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20180430/bc3d992c/attachment.html>