- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
public boolean isModified() {
return
!pluginEnabled.isSelected() == getSettings().pluginEnabled
|| !pathToContainerTextField.getText().equals(getSettings().pathToProjectContainer)
|| !pathToUrlGeneratorTextField.getText().equals(getSettings().pathToUrlGenerator)
|| !symfonyContainerTypeProvider.isSelected() == getSettings().symfonyContainerTypeProvider
|| !objectRepositoryTypeProvider.isSelected() == getSettings().objectRepositoryTypeProvider
|| !objectRepositoryResultTypeProvider.isSelected() == getSettings().objectRepositoryResultTypeProvider
|| !twigAnnotateRoute.isSelected() == getSettings().twigAnnotateRoute
|| !twigAnnotateTemplate.isSelected() == getSettings().twigAnnotateTemplate
|| !twigAnnotateAsset.isSelected() == getSettings().twigAnnotateAsset
|| !twigAnnotateAssetTags.isSelected() == getSettings().twigAnnotateAssetTags
|| !phpAnnotateTemplate.isSelected() == getSettings().phpAnnotateTemplate
|| !phpAnnotateService.isSelected() == getSettings().phpAnnotateService
|| !phpAnnotateRoute.isSelected() == getSettings().phpAnnotateRoute
|| !phpAnnotateTemplateAnnotation.isSelected() == getSettings().phpAnnotateTemplateAnnotation
|| !yamlAnnotateServiceConfig.isSelected() == getSettings().yamlAnnotateServiceConfig
;
}
Int 28.06.2013 12:15 # 0
inkanus-gray 28.06.2013 12:20 # +4
И да, в данном коде != не нужно, поскольку есть законы де Моргана.
guest 28.06.2013 18:57 # +4
inkanus-gray 28.06.2013 20:29 # 0
guest 05.07.2013 18:17 # 0
хуйню написал
inkanus-gray 28.06.2013 12:32 # +1
kostoprav 28.06.2013 12:36 # +1
roman-kashitsyn 28.06.2013 12:36 # +4
щас, ага.
Я так понимаю, здесь сравнивают состояние UI с конфигом, чтобы понять, были реальные изменения (т.е. не "подёргивания") или нет.
Объекты разнородные, мне вот сложно более удобную схему придумать. Чейндж-листенеры не аналогичны, ибо они не смогут распознать "подёргивания".
defecate-plusplus 28.06.2013 12:41 # +6
roman-kashitsyn 28.06.2013 12:47 # +1
neeedle 28.06.2013 13:10 # 0
inkanus-gray 28.06.2013 13:08 # 0
roman-kashitsyn 28.06.2013 13:15 # +3
inkanus-gray 28.06.2013 13:17 # +4
roman-kashitsyn 28.06.2013 13:34 # +6
someone 28.06.2013 15:17 # 0
> Объекты разнородные, мне вот сложно более удобную схему придумать.
Всё правильно. Тут одним сравнением не отделаешься.
Если бы были объекты одного типа, можно было бы сделать EqualsBuilder.reflectionEquals.
А вообще я использую Lombok, и там есть @EqualsAndHashCode (а ещё @Getter, @Setter, @ToString и @Data). И это хорошо.
Lure Of Chaos 28.06.2013 13:40 # 0
kostoprav 28.06.2013 13:49 # 0
Lure Of Chaos 28.06.2013 14:13 # 0
и все равно от "длинных" "подергиваний" не спасет (когда 3е состояние не равно 2ому, но равно уже "забытому" 1ому)
ну и имхо это ничего страшного.
kostoprav 28.06.2013 14:22 # 0
То спасать должно... Или я не прав?
Lure Of Chaos 28.06.2013 15:18 # 0
не будете же вы хранить всю историю изменений. да и даже если будете, то как определите, где подергивание, а где желаемое состояние?
kostoprav 28.06.2013 15:23 # 0
- меняем А, признак устанавливается
- меняем Б, признак установлен
- возвращаем А назад - вот тут важно понять, что признак должен остаться установленным...
Поэтому я и предложил битовую маску
Lure Of Chaos 28.06.2013 15:33 # 0
roman-kashitsyn 28.06.2013 15:40 # 0
wvxvw 28.06.2013 14:51 # 0
ЗЫ.
kostoprav 28.06.2013 14:52 # +1
anonimb84a2f6fd141 30.06.2013 19:25 # −3