Так может проблема во включенном GPS приемнике, а не запущенных программах? Если «убить» программы, GPS все равно вроде будет продолжать работать, или я не прав?
Ну, а вообще, конечно, google имеет тенденцию валить вину на разработчиков ПО, которые «неправильно» пишут программы, из-за чего быстро садится зарядка.
"… Но когда вы, затянув пояса, соберете денежки и купите наконец машину – предел ваших мечтаний, она моими стараниями давным-давно выйдет из моды. Я ведь иду на три круга впереди вас и, уж будьте уверены, позабочусь о том, чтобы вы чувствовали себя облапошенными"
Ф. Бегбедер 99 франков.
Так что люди там знают свое дело.
Пишите все имена с маленькой буквы, особенно имена классов, а потом создавайте переменные с таким же именем: user user = new user(); Только представьте сколько времени можно сэкономить забыв про клавишу Shift, а потом потратить его на дублирование функциональности!
Ну так ведь AJDT имеет много возможностей. Он показывает при разработке какие строчки кода затронуты аспектами. В аспекты можно заходить при отладке. Ну и т.д.
Использование аспектов характерно для текущей реализации. Я бы охотно выслушал другие предложения. Была идея использовать classloader'ы и модифицировать байткод. Может кто подаст идею?
Представьте, допустим, что диалектические переменные войдут в спецификацию Java и их реализация будет лишена недостатков производительности. Это бы поменяло ваше отношение?
Спасибо за комментарий. Во многом с вами согласен.
>Не оговорено, что будет происходить, если объявим две диалектических переменных, каждая из которых при каком-то ограничении должна себя вести как другой класс. Допустим, сработают оба условия. Какой класс в итоге будет выбран?
Как я уже говорил, я планирую добавить проверку на бесконфликтность диалектических переменных.
> Если в какой-то точке происходит Exception (наиболее простой случай), то понять, какие были значения переменных на момент его возникновения становится намного сложнее.
Не совсем понятно почему. Нельзя понять какие будут значения переменных на этапе компиляции из-за тех же ветвлений, но во время выполнения что нам мешает выводить в лог нужную информацию?
>Код становится менее прозрачным. Почему? Потому что интуитивно читая new ожидаешь поведения того объекта, который ты создал… думать в момент реализации о всех возможных вариантах — это очень сложно.
Соглашусь, сложно. Но так ведь полиморфизм неотъемлемая часть ООП. Значит надо стараться писать код так, чтобы учитывать полиморфное поведение объекта, это в принципе не так сложно.
И конечно, класс в котором есть диалектические переменные должен быть хорошо документирован, и когда человек использует эти классы, он должен знать о подобном поведении объектов.
>Предложенная же концепция диалектических переменных наоборот увеличивает сложность.
Я как раз сейчас думаю можно ли как-то это упростить… Если есть идеи буду рад выслушать. При чем как по подходу так и по реализации
Ну, а вообще, конечно, google имеет тенденцию валить вину на разработчиков ПО, которые «неправильно» пишут программы, из-за чего быстро садится зарядка.
Ф. Бегбедер 99 франков.
Так что люди там знают свое дело.
Хорошая новость. Известно как это будет выглядеть и работать?
Ну а кошка просто уверена, что они боги
Представьте, допустим, что диалектические переменные войдут в спецификацию Java и их реализация будет лишена недостатков производительности. Это бы поменяло ваше отношение?
>Не оговорено, что будет происходить, если объявим две диалектических переменных, каждая из которых при каком-то ограничении должна себя вести как другой класс. Допустим, сработают оба условия. Какой класс в итоге будет выбран?
Как я уже говорил, я планирую добавить проверку на бесконфликтность диалектических переменных.
> Если в какой-то точке происходит Exception (наиболее простой случай), то понять, какие были значения переменных на момент его возникновения становится намного сложнее.
Не совсем понятно почему. Нельзя понять какие будут значения переменных на этапе компиляции из-за тех же ветвлений, но во время выполнения что нам мешает выводить в лог нужную информацию?
>Код становится менее прозрачным. Почему? Потому что интуитивно читая new ожидаешь поведения того объекта, который ты создал… думать в момент реализации о всех возможных вариантах — это очень сложно.
Соглашусь, сложно. Но так ведь полиморфизм неотъемлемая часть ООП. Значит надо стараться писать код так, чтобы учитывать полиморфное поведение объекта, это в принципе не так сложно.
И конечно, класс в котором есть диалектические переменные должен быть хорошо документирован, и когда человек использует эти классы, он должен знать о подобном поведении объектов.
>Предложенная же концепция диалектических переменных наоборот увеличивает сложность.
Я как раз сейчас думаю можно ли как-то это упростить… Если есть идеи буду рад выслушать. При чем как по подходу так и по реализации