@tieskedh You're killing me here 🙂 Hehe..

haha, you're busy with the old pull request?

if possible, evaluate per commit

@tieskedh Looking at the new now. Why do you call the builder rootBuilder in fragment and rootGenerator in View? And why is it only lazy in View?

accident, thx, nothing needs to be lazy. I think the right name is rootBuilder?

That sounds right. I also wonder about the usefulness of these things.

Torn.

I don't particularly like the resulting syntax either to be honest.

I only like it without aditional parameters

It's so simple that you can't declare local fields, so if people start using this they would have to convert to a normal View down the stretch. This will just cause irritation.

All you save is

override val root =

, really.

so, we can limit to that. I meant this for the small classes. When a class is big, it is indeed better not to use Simple View...

I picked this up at almost all the testing frameworks. but we can remove it, but let me close it 😉

Yeah, I think it will be wise to close this. There isn't much value, just potential irritation for users. A small class quickly turns to a bigger class, and we don't want to have to decide if you ever are going to add local properties to a View when you create it. We also have the builderFragment function for example, which is less boilerplate than this, and is good for those simple views.

About #452 - it's hard to deal with because it's so large/spanning different domains. It would be better if PRs are kept to one problem domain.

I will try to deal with 452 as it is though 🙂

I don't like +=/-= for classes, add/remove is much more clearer IMO.

OK! Maybe you can look over them and I'll have another look at them tomorrow? I have to get to bed now 🙂

I wanna thank you for all your hard work in improving the syntax and robustness of the framework. Great job!

I thought I reverted some changes, but all the changes that are now in the branch are in my opinion correct. I don't like the add/remove, but I will change this back to their original state...

sleep well

@edvin @tieskedh I'm not crazy about infix in general. When I started with C++, there was a lot of operator overloading but it wasn't always clear what the operators did even if they could be explained rationally after-the-fact.

@carlw infix or operator?

mainly operator, but i'm thinking specifically about some +'s many years ago

I have a Swift project too and have been keeping my eyes on syntax like this https://www.raywenderlich.com/80818/operator-overloading-in-swift-tutorial

(3 year old article)

Yeah, it doesn't always make things clearer.

Some times a well placed verb is easier to understand.

And.. it allows for chaining calls, which goes out the window with operators.

The big difference with korlin is that all operators are well defined