Add Object.toMixin() method

[Mikulas]

Adds a toMixin() method to the Object class that converts an Object
into a Mixin function applicable via the pipe operator (|>).

A generic toMixin() method cannot be implemented in user land, so this
implementation provides a native method that properly handles:

• Property merging and overriding
• Element appending with correct index offsetting
• Entry merging with proper key handling
• Nested object replacement vs amendment semantics

Implementation uses the source Object's enclosing frame to ensure
proper module context for type resolution during member evaluation.

edit: updated from Dynamic to Object

[HT154]

Can this not be done in userland Pkl?

function dynamicToMixin(mix: Dynamic): Mixin = new {
  ...mix
}

It's likely that the "deep" variant of this that recursively turns a nested object structure (and not just a Dynamic!) into a Mixin isn't userland-friendly, but I'm not sure there needs to be an API for the shallow implementation.

Missed the implementation detail that makes this work, never mind :)

[Mikulas]

@HT154 I don't believe so due to how amends vs replacements are constructed. Consider this example:

local base = new {
  a1 {
    b1 = 2
  }
  a2 {
    b1 = 2
  }
}

local over = new Mixin {
  a1 = new Dynamic {
    b2 = 2
  }
  a2 {
    b2 = 2
  }
}

local overrideValue = new Dynamic {} |> over

function dynamicToMixin(mix: Dynamic): Mixin = new {
  ...mix
}

actualValue = base |> dynamicToMixin(overrideValue)

expectedValue = base |> over

Which evaluates to

actualValue {
  a1 {
    b2 = 2
  }
  a2 { // ❗️This is not correct, the original Mixin has amend semantics here, not replace
    b2 = 2
  }
}
expectedValue {
  a1 {
    b2 = 2
  }
  a2 {
    b1 = 2
    b2 = 2
  }
}

[Mikulas]

Updated to implement on Object rather then Dynamic

[HT154]

This looks great!

[HT154]

Here are a few un-tested cases I can think of that I'd like to see covered:

• Applying mixins with properties/entries to Listings (and other variants of this wrong-member-type error)
• Apply Mixin<Listing> to a Dynamic (and other variants; except Dynamic |> Mixin<some Typed> which is covered)
• Applying an object's mixin to the original object (obj |> obj.toMixin())
• Applying a mixin to an object that would induce a stack overflow (new Dynamic { foo = bar } |> new Dynamic { bar = foo }.toMixin())

[Mikulas]

This is great! Actually caught an issue with Listings where it was incorrectly overwriting keys. Now it correctly amends keys, same as explicit Mixin declaration does.

[HT154]

A few more FQCNs still hanging around:

Suggested change

	@CompilerDirectives.TruffleBoundary
	private static org.graalvm.collections.UnmodifiableEconomicMap<Object, ObjectMember> adjustMemberIndices(
	org.graalvm.collections.UnmodifiableEconomicMap<Object, ObjectMember> members,
	long parentLength) {
	if (parentLength == 0) {
	return members;
	}
	var result = org.pkl.core.util.EconomicMaps.<Object, ObjectMember>create(
	org.pkl.core.util.EconomicMaps.size(members));
	var cursor = members.getEntries();
	while (cursor.advance()) {
	var key = cursor.getKey();
	var member = cursor.getValue();
	// If this is an element (not an entry with an Int key), offset the index
	if (member.isElement()) {
	// Elements always have Long keys
	var newKey = (Long) key + parentLength;
	org.pkl.core.util.EconomicMaps.put(result, newKey, member);
	} else {
	// Properties and entries are not offset
	org.pkl.core.util.EconomicMaps.put(result, key, member);
	@TruffleBoundary
	private static UnmodifiableEconomicMap<Object, ObjectMember> adjustMemberIndices(
	UnmodifiableEconomicMap<Object, ObjectMember> members,
	long parentLength) {
	if (parentLength == 0) {
	return members;
	}
	var result = EconomicMaps.<Object, ObjectMember>create(EconomicMaps.size(members));
	var cursor = members.getEntries();
	while (cursor.advance()) {
	var key = cursor.getKey();
	var member = cursor.getValue();
	// If this is an element (not an entry with an Int key), offset the index
	if (member.isElement()) {
	// Elements always have Long keys
	var newKey = (Long) key + parentLength;
	EconomicMaps.put(result, newKey, member);
	} else {
	// Properties and entries are not offset
	EconomicMaps.put(result, key, member);

[HT154]

This should return the same type as sourceObject, so you'll need to choose the right VmObject subclass to build here. We definitely want this invariant to hold:

local base = new Bird { name = "Parrot"; age = 20 }
local birthday = new Bird { age = super.age + 1 }.toMixin()
local aged = base |> birthday
invariant = base.getClass() == aged.getClass()

[bioball]

This behavior seems obviously wrong, and is what this implementation currently does.

local foo {
  a = 1
}

local bar = (foo) {
  b = 2
}

res = new Dynamic {} |> bar.toMixin()

Produces:

res {
  b = 2
}

However, respecting the amends chain is somewhat problematic for Typed.toMixin():

class MyClass {
  a: Int
  b: Int
}

res: MyClass = new MyClass { a = 1; b = 2 }
  |> new MyClass { a = 1 }.toMixin() // would throw "cannot read property `a`" if respecting the amends chain

This feature sounds good in theory, but has some nuances that are hard to resolve. Also, this definitely needs a SPICE to guide the design!