On Wed, Feb 15, 2017 at 9:43 AM, Daniel Dekany <ddek...@freemail.hu> wrote: > BTW, Configuration.Builder or ConfigurationBuilder? Both convention > exists in the wild. I have recently noticed that the Java API is using > Xxx.Builder at some places, so maybe that will be the more popular > convention. It surely has the advantage that it can call a private > constructor of the built class (or access other private members of > it).
I'm fine with either way, but Configuration.Builder seems to have more benefit like you mentioned, trading off the code size in single file (which might be okay with help of IDEs nowadays). Woonsan > > Wednesday, February 15, 2017, 12:30:30 PM, brede...@me.com wrote: > >> +1 for ConfigurationBuilder >> >> -- Denis. >> Original Message >> From: Daniel Dekany >> Sent: Wednesday, 15 February 2017 10:49 >> To: Woonsan Ko >> Reply To: dev@freemarker.incubator.apache.org >> Subject: [FM3] Configuration mutability (Was: [FM3] Configuration API >> simplification) >> >> Wednesday, February 15, 2017, 12:16:12 AM, Woonsan Ko wrote: >> >>> Also, if possible, I would like to have an immutable object or >>> representation than the Configuration itself. For example, >>> template#getConfiguration doesn't have to return a mutable object, for >>> instance. But it requires a bigger change, I guess. >> >> A good point, that's the totally correct way of doing things. So we >> could have a mutable Configuration.Builder, which yields an immutable >> Configuration. We also have some ObjectWrapper, which is a bean in >> itself, but is also part of the Configuration. We certainly will have >> another such "injected bean", the TemplateResolver, and maybe some >> more on long term. Those also could follow this pattern (i.e, being >> immutable and only offer a builder). >> >> Question is, what extra pain that means for the average user. Like >> then in Spring XML you have to create a factory bean from Xxx.Builder, >> and then create yet another bean with factory-bean and factory-method >> attribute (because for some reason javax.annotation doesn't have >> anything like Spring FactoryBean, and freemarker-core can't depend on >> Spring obviously). Or, we can subclass all builders in something like >> freemarker-spring, to create a FactoryBean version of them, and then >> tell people to (a) pull in the depednecy and (b) use those classes >> instead of those shown in the core JavaDoc and in the Manual >> examples... So it's not very streamlined. If you have traditional >> beans, it's simpler for the users (especially if they don't have a >> PostConstruct either). Note sure which compromise is the winner. >> >> If Configuration (and the others) remains a bean, I want to throw an >> IllegalStateException if a the object were already "used" (like >> template processing was already invoked), and then someone calls >> cfg.setXxx(value). In FM2 we say that if you do that from multiple >> threads, then it won't work correctly, but we allow changing the >> Configuration at any time if you are only using it from the same >> thread. That's a possibility I want to remove, even if we don't switch >> to builders. >> >> Oh, and yet another complication with builders... If Configuration is >> immutable, then it only will have getters, no setters. But, >> Environment is mutable with setters, and it should be. Both >> Configuration and Environment extends Configurable. So it seems now we >> should split that class into a getters-only class and a subclass that >> adds setters... (That might will be necessary because that Template is >> mutable with setters is not all right either. Or we can just throw >> IllegalStateException there too.) >> > > -- > Thanks, > Daniel Dekany >
