Records

[phax]

Based on #126

[glelouet]

The record components should be used as variables too.

JRecordTest::testRecordWithCompactConstructor should use record components directly

		JRecordComponent lo = rec.recordComponent (cm.INT, "lo");
		JRecordComponent hi = rec.recordComponent (cm.INT, "hi");
 …
		compactCtor.body ()
							 ._if (lo.gt (hi))

Same on the next test methods testRecordWithCanonicalConstructor

Make JRecordComponent implement IJExpression ? Only default methods AFAIK, parent IJGenerable::generate already implemented since JRecordComponent implements IJGenerable.

[phax]

Yes, I've seen this too and tried making JRecordComponent and IJAssignmentTarget but it lead to invalid code. I guess we would need a JRecordComponentRef class instead

[glelouet]

can't be assignment target, it's const.

[phax]

Inside the constructor it is assigned to

[glelouet]

Yeah, also in future "with" it will be.

[phax]

@glelouet better?

[glelouet]

What do you mean by inside the constructor through ?
@phax

Ho I get it. Constructors of the record can set their own value, eg

Range(T min, T max){
 Range(Pair<T> p){
   this.min=p.first;
  this.max=p.second;
 }
}

[phax]

Syntactic sugar with fixed coding styleguide for getters and setters ;-)

[glelouet]

@phax The modified parts are better indeed, but the rest of the test is still to be changed ? (Not complaining, just stating)

[phax]

Feel free to complain ;-) Noted

[glelouet]

Syntactic sugar with fixed coding styleguide for getters and setters ;-)

Yeah I like that refthis can take a record into account. Something required when doing, say, record constructors :P

[glelouet]

Feel free to complain ;-) Noted

No point in complaining if that's not brought alongside an improvement effort.

[glelouet]

@phax

As a side note can we also have a throw() expression that takes a Class<? extends exception> or a codemodelreference as a parameter ?

I just realize the

				._throw (JExpr._new (cm.ref (IllegalArgumentException.class)));

Could definitely be improved into

				._throw (IllegalArgumentException.class);

If JBlock had a sugar coating corresponding method.

[phax]

Will do it later - have other priorities atm

[glelouet]

There is no codemodel reference in the JBlock so only using AbstractJClass ; added second method in JBlock :

	@NonNull
	public JThrow _throw (@NonNull final IJExpression aExpr)
	{
		return internalInsert (new JThrow (aExpr));
	}
	
	@NonNull
	public JThrow _throw (@NonNull final AbstractJClass throwClass)
	{
		return _throw (JExpr._new( throwClass));
	}

Only saves a _new call, not sure if worth.

[glelouet]

@phax can you show me where it is allowed to assign values to the record fields ?

I could not find a way in https://docs.oracle.com/en/java/javase/25/language/records.html#GUID-6699E26F-4A9B-4393-A08B-1E47D4B2D263

On the opposite, I found

You can define alternative, noncanonical constructors whose argument list doesn't match the record's type parameters. However, these constructors must invoke the record's canonical constructor.

Which implies that there is no assignment ?

edit : okay it's in the cannonical constructor.

        this.length = length;
        this.width = width;

[phax]

Took your proposal in - seems like a good compromise

[glelouet]

maybe could even add a varagar of params to pass to the _new call.
example use case _throw(cm.ref(UnsupportedOperationException.class), Jexpr.lit("case not supported") );

Just an idea though.

=> (only second method changed)

	@NonNull
	public JThrow _throw (@NonNull final IJExpression aExpr)
	{
		return internalInsert (new JThrow (aExpr));
	}
	
	@NonNull
	public JThrow _throw (@NonNull final AbstractJClass throwClass, IJExpression... params)
	{
		JInvocation init = JExpr._new( throwClass);
		if(params!=null )
		{
			for(IJExpression ije : params)
			{
				init.arg(ije);
			}
		}
		return _throw (init);
	}

[phax]

Good idea - done. But using a separate method

[glelouet]

@phax the null test was because the varargs was allowed null.
If you split in two cases : no varargs XOR varagars nonnull, no need to test for nullity in the second one.

[phax]

you can't have enough null checks ;-)