Есть ли какие-либо планы относительно “дополнительных свойств” в будущей версии C#?
Я сам нашел причину. Я использовал permisson com.example.permission.MAPS_RECEIVE, который уже использовался моим предыдущим пакетом. Я удалил это разрешение (смотрите здесь: Android Map V2 - почему разрешение MAPS_RECEIVE ), и оно заработало.
Я не знаю, является ли это лучшим решением, но оно работает в первых нескольких тестах.
6 ответов
Официальным сайтом для запросов новых функций является http://connect.microsoft.com/VisualStudio.
Уже был запрос на дополнительные свойства здесь.
Ответ Microsoft на 29.07.2008 включал следующее:
Дополнительные свойства являются общим запросом, и мы на самом деле стали довольно далекими с дизайном для следующей версии языка, но в конечном счете должны были фрагментировать его из-за различных трудностей. Это находится все еще на нашем радаре.
Обычно я думаю, что это поощрило бы плохую практику. Свойства, как предполагается, представляют некоторое состояние о рассматриваемом объекте, тогда как методы должны представить единицы работы. Но многие разработчики склонны помещать в вычислительном отношении интенсивный или относительно продолжительный код в методы считывания и методы set, где они были бы намного более соответствующими как методы. Расширение объекта не является тем же как происходящий из него. Если необходимо добавить свойства, с философской точки зрения Вы говорите о необходимости добавить информацию с сохранением информации к объекту. Это должно быть сделано путем получения из класса.
Хотя я не думаю, что Вы предлагаете, хорошая идея, можно получить в значительной степени то же самое с предстоящим dynamic введите в C# 4. Часть того, что планируется, должна позволить новым свойствам и методам быть добавленными во времени выполнения к существующим объектам и типам. Одно различие - то, что у Вас не будет времени компиляции, проверяя дополнительного свойства.
Могло бы быть что-то, чтобы быть сказанным о таком приеме.
Только посмотрите на Приложенные свойства в WPF. Они действительно дают огромное питание для декларативного вложения поведения. Но я не уверен, на что это было бы похоже за пределами декларативного контекста...
Я не уверен, как это работало бы. Расширения должны быть статичными, таким образом, само свойство имело бы к помехам. Средства вообще, которые Вы используете для поддержки этих свойств, также были бы статичны. Но ожидайте, что Ваше запланированное использование для них ожидает, что они будут связаны с экземплярами, обозначенными this ключевое слово, а не сам тип.
"Дополнительные свойства" доступны сегодня через наследование. Добавление такого зверя поощрило бы плохие методы ООП и обычно было бы большей проблемой, чем ее ценность.