Yep, that is true and caused issues for the calendar formfield.
However the issue as much that this function is called twice, that is perfectly fine.
creator of formfields need to make sure they don't do those calculations in that method. It is meant to just fetch the data for the layout. It is not meant to do value processing. Those should be done in the getInput or getLabel methods.

So imho this isn't an issue, developers just need to use it correctly.

I am agree and not agree ?

So imho this isn't an issue, developers just need to use it correctly.

Yes, but it not obviously. That's where the problem.
Instead of just doing :

function getLayoutdata()
{
 // prepare my data
}

I should do extra check:

function getLayoutdata()
{
 if(empty($this->data)){
   // prepare my data
 }
}

The developer will come to this solution only by accident or when get some bug.

So for me it is issue in the logic of JField class.

Why do you even some data processing in that method? Even the if (empty($this->data)){ approach looks wrong to me. Data processing shouldn't be done in this method at all. It should just be some data "collecting" and maybe prepare it for display (but not alter the original source).

I agree it was done wrong in core when the stuff from the getInput methods just was moved to that new getLayoutData method. It's corrected for the calendar formfield, are there other places in core where this is an issue?

I also haven't really looked at why the method even exists, I just assumed it's related to the move to JLayouts and prepares the data for those JLayouts.

I also haven't really looked at why the method even exists, I just assumed it's related to the move to JLayouts and prepares the data for those JLayouts.

Because otherwise you just pass the entire form field object into the layout which is a crap answer (a well encapsulated layout in a well designed templating system will only have the specific data it is injected available, not the entire application and most assuredly not the entire API of wherever the layout is called from because there is massive scope creep and no encapsulation). Passing the entire class object has its own problems, see issues where the existing logic of just dumping JViewLegacy objects into layouts has caused issues with data re-use in incompatible contexts.

Why do you even some data processing in that method?

Previously we had just getInput(), and all data processing usually was there.
Now when we have possibility to use the layout to render the input, all data processing will be moved to getLayoutdata, and getInput() can be inherited from JFormField::getInput.

It is what happened with the calendar field, and will happen with other fields, I guess.

And try to decide which data should be collected by getLayoutdata and what should be processed in getInput, also not easy question ? ... it actually complication

Because otherwise you just pass the entire form field object into the layout

Yeah, that's what I assumed ?

all data processing will be moved to getLayoutdata

That's where it got wrong. Data processing shouldn't be done in that method. It should still be done in the getInput.

And try to decide which data should be collected by getLayoutdata and what should be processed in getInput

Actually it's easy. getLayoutdata is only for the display part itself. It should take the needed data and put it into an array ( $displayData). Everything else and especially anything which alters any property of the field class has to be in the getInput / getLabel methods.

Actually it's easy

Not for Joe Average ?

What could we do to make it more obvious? Adding better method comment? Currently it says

Method to get the data to be passed to the layout for rendering.

No idea. It is one of reason why I have opened the issue ?
Maybe better description then. Or at least some warning about such behavior.

Seems to me a non issue, closing for now