Здравствуйте, _pk_sly, Вы писали:
__>а я могу. и пользовался этим. __>и разработчики C# тоже, очевидно, могли, если учли это в спецификации. __>даже в COM такая возможность присутствует.
А на основании что в КОМ присутсвуют ГУИД-ы и т.п. не надо все это добавить в дотнет?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Добавил поддержку auto-property (как в C# 3.0)
Здравствуйте, VladD2, Вы писали:
IT>>Смысла нет пока тебе это самому не понадобилось. Как понадобится, так сразу и смысл появится.
VD>Смыла нет потому что нет смысла.
Я так и думал
VD>Ты можешь показать хоть какое-то применение для того о чем ты говришь?
Нет. А ты можешь доказать, что такое применение не найдётся в будущем?
Ну да ладно, это в принципе ерунда. Ты мне лучше вот что скажи. Такое поведение можно будет изменить макросами или это теперь прибито гвоздями навсегда?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Добавил поддержку auto-property (как в C# 3.0)
Здравствуйте, IT, Вы писали:
VD>>Ты можешь показать хоть какое-то применение для того о чем ты говришь?
IT>Нет. А ты можешь доказать, что такое применение не найдётся в будущем?
Самая большая ошика программистов — это попытки реализовать супер универсальные вещи учитывающие все что может произойти в будущем. Я по этим граблям уже ходил и теперь стараюсь их обходить. Так что когда появятся осмысленные варианты, можно вернуться к этому вопросу и если что поменять код. Он гвоздями не прибит. Мы все же не в Microsoft арботаем.
IT>Ну да ладно, это в принципе ерунда. Ты мне лучше вот что скажи. Такое поведение можно будет изменить макросами или это теперь прибито гвоздями навсегда?
Сейчас код рабоает на стадии создания PropertyBuildero-ов. Собственно из самого кода видно, что он распознает паттерн { get; set; } в свойствах которые не являются абстракными, внешними или свойствами интерфейса. Стало быть если до этого момента кто-то изменит код гетера или сетера, то этот код просто не узнает паттерн. Так что если создать макрос который отработает раньше (на стадии BeforeTypedMembers или BeforeInheritance) и сам проделает похожую работу, то (теоретически) мой код не отработает.
В принципе можно даже создать событие к котому можно было бы подключиться и которое отработало бы при выполнении этого кода, но не уверен, что это нужно. Предпочитаю дождаться наличия такой необходимости, а уже потом думать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Добавил поддержку auto-property (как в C# 3.0)
Здравствуйте, VladD2, Вы писали:
VD>Самая большая ошика программистов — это попытки реализовать супер универсальные вещи учитывающие все что может произойти в будущем.
Не учите меня жить, лучше помогите материально (c)
VD>Сейчас код рабоает на стадии создания PropertyBuildero-ов. Собственно из самого кода видно, что он распознает паттерн { get; set; } в свойствах которые не являются абстракными, внешними или свойствами интерфейса. Стало быть если до этого момента кто-то изменит код гетера или сетера, то этот код просто не узнает паттерн. Так что если создать макрос который отработает раньше (на стадии BeforeTypedMembers или BeforeInheritance) и сам проделает похожую работу, то (теоретически) мой код не отработает.
Понятно. Будем надеяться, что проблем не будет.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Добавил поддержку auto-property (как в C# 3.0)
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, VladD2, Вы писали:
IT>>>Смысла нет пока тебе это самому не понадобилось. Как понадобится, так сразу и смысл появится.
VD>>Смыла нет потому что нет смысла.
IT>Я так и думал
Если нет смысла то есть ли хотя бы логика смысла?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Добавил поддержку auto-property (как в C# 3.0)
VD>А на основании что в КОМ присутсвуют ГУИД-ы и т.п. не надо все это добавить в дотнет? ;)
ага, можно ещё вспомнить модель памяти huge. или поддержку win16.
только к делу это не относится.
в дотнет readonly/writeonly надо было бы добавить на основании того, что это — полезная фича, которая НИЧЕГО не стоит разработчикам. ну, слава богу, в дотнете она присутствует, так что о её полезности можно было спор не начинать.
Re[7]: Добавил поддержку auto-property (как в C# 3.0)
Здравствуйте, _pk_sly, Вы писали:
__>в дотнет readonly/writeonly надо было бы добавить на основании того, что это — полезная фича, которая НИЧЕГО не стоит разработчикам. ну, слава богу, в дотнете она присутствует, так что о её полезности можно было спор не начинать.
Полезного в ней ничего нет. Для особо упетрых есть возможность прописать свойство с сетерром и без гетера врунчую. Автоматизировать создание этого идиотизма лично я не собираюсь. И всеми силами буду сопротивляться этому.
Если сам не понимашь в чем проблема свойств без гетеров, то поясню.
Дело в том, что свойство — это публичный интерфейс к состянию объекта. Свойство доступное только для чтения полезно для неизменяемых объектов (состояние которых задается при создании) и для случаев когда изменение свойства влечет серьезное изменение других аспектов состояния объекта (или просто занимает много времени). В таких сучаях имеет смысл делать свойство доступное из вне только для четения, а модификацию состояния производить с помощью функции (которая может иметь множество параметров).
Наличие же свойства доступного только на запись, говорит, что собственно свойства описывающего состояние в общем-то и нет. Смысл такого свойства только в побочном эффекта. Свойства вообще в идиале не должны менять ничего кроме самих себя (ну, разве что еще связанные свойства, например, если объект выдает значение в часах и днях, то логично при зименении одного из представлений менять и другое). А уж когда оно используется исключительно для зименения состояния, то возникает ощущение, что люди проектировавшие объект просто не знакомы с приципами ОО-дизайна.
В таких случаях унжно пользоваться методом, чтобы пользователь объекта не удивлялся тому, что не может считать состояние только что заданному свойству.
Попробуй ради хохмы найти в дотнете хотя бы один класс с такими свойствами. Или скажем в компиляторе того же Немерле (там не мало кода).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Добавил поддержку auto-property (как в C# 3.0)
Здравствуйте, VladD2, Вы писали:
VD>Полезного в ней ничего нет. Для особо упетрых есть возможность прописать свойство с сетерром и без гетера врунчую. Автоматизировать создание этого идиотизма лично я не собираюсь. И всеми силами буду сопротивляться этому.
Самая большая ошика разработчиков библиотек и прочего инструментария — это попытки решить за других что им будет нужно, а что нет. Особенно, когда сделать чуть гибче и удобнее практически ничего не стоит.
VD>Дело в том, что свойство — это публичный интерфейс к состянию объекта.
Свойство — это синтаксический сахар. В джаве свойств нет вообще и без них там прекрасно обходятся. Во многих случаях вместо свойств совершенно спокойно можно использовать публичные поля и никаких проблем не будет. Эта практика в своё время была объявлена кое-кем плохой, но как оказалось, плохого в ней только лишь то, что этот кое-кто криво реализовал TypeDescriptor, который понимает только свойства. Но проблема эта лечится, после чего публичные поля становятся ничем не хуже свойств.
VD>Наличие же свойства доступного только на запись, говорит, что собственно свойства описывающего состояние в общем-то и нет. Смысл такого свойства только в побочном эффекта.
А метод принимающий один параметр и называющийся SetSomething — это нормально или тоже кривой дизайн.
VD>Свойства вообще в идиале не должны менять ничего кроме самих себя
Тогда чем они лучше публичных полей?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Добавил поддержку auto-property (как в C# 3.0)
IT>Самая большая ошика разработчиков библиотек и прочего инструментария — это попытки решить за других что им будет нужно, а что нет. Особенно, когда сделать чуть гибче и удобнее практически ничего не стоит.
Не. Самая большая ошибка — это делать что-то прозапас. При этом неминуемо получаются кривые и никому не нужные решения в то время как на полезные просто не хватает внемени и сил.
VD>>Свойства вообще в идиале не должны менять ничего кроме самих себя
IT>Тогда чем они лучше публичных полей?
Тем, что на них нельзя получить ссылку. И тем что они могут быть частью интерфейса в отличии от полей. Так же полезна возможность изменять область видимости сеттера, хотя это в как раз больше полезно для авто-свойств.
ЗЫ
Это последнее мое сообщение в этом обсуждении. Попобую обяснить ситуацию. Автосвойства — это продуманное решение. Продуманное не по одному критерию "ах какая приятная рюшечка", а по массе критериев, от совестимости со старым кодом, до локаничности и безопасности. И самое главно понятно зачем это нужно. Делать же то что "может пригодиться кому-то там" я принципиально не считаю нужным, точнее считаю вредным. С удовольствием изменю свое решение если мне будут предоставлены внятные аргументы.
Пока что я вижу четкую связь между уровнем программиста и желанием налепить решений вроде свойств доступных только для записи. И пусть лучше их лень приведет к тому, что они невольно будут избегать плохих решений.
В прочем, они конечно, могут тупо пометить getter как private и получить, что называется, что заслужили.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Добавил поддержку auto-property (как в C# 3.0)
Кстати... чем мне действительно нравится ОпенСорс, так это тем, что нет нужды долго ждать от дяди когда он проникнится нужностью той или иной фичи и реализует ее для меня. Я могу просто сесть и сделать. В закрытом софте создание фич на всякий пожаерный стандартная практика. Вдруг не сделаем что-то что нужно народу? В ОпенСорсе же все с точностю до наоборот. Нужную фичу всегда можно добавить. Так что если возникнет реальная потребность, то нет особых проблем. Можно даже макросом то что нужно реализовать. Посему жить по принципу "вдруг" просто бессмысленно. Как толко это вдруг станет очевидным, то можно воплотить свои мечты в реальность.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
И то, и другое хорошо когда в меру.
Пытаться предусмотреть всё и вся приводит к ASP.Net с его PreInit/Init/PreLoad/Load/PreRender там где за глаза хватит двух методов.
Не делать ничего про запас приведёт к монолиту вроде MFC.
Так что хватит ругаться и давайте лучше обсудим, что можно добавить в автосвойства.
Мне вот хочется иметь возможность хранить такие свойства во внешних контейнерах.
Поясню зачем. В том же самом ASP.Net у объектов типа страничка или контрол понятие экземпляра очень короткоживущее.
Фактически объект создаётся каждый раз при получении "GET blablalba HTTP/1.1" и грохается после ответа сервера.
Чтобы это объехать, придуманы три коллекции: ViewState, Session и Application.
И там, где нужно завести на странице свойство, приходится писать что-то вроде
public PageNo : int
{
get { ViewState["PageNo"] :> (int?) ?? 0; }
private set { ViewState["PageNo"] = value; }
}
Если нужно десть свойств, то такая фигня копипастится 10 раз. А вообще-то это мусор. И он только затрудняет чтение исходников.
Гораздо проще для понимания вот такое:
[Storage(ViewState), DefaultValue(0)] public PageNo : int { get; private set;}
Тут совершенно ясно, что происходит и лушние детали в глаза не лезут.
Здравствуйте, Блудов Павел, Вы писали:
БП>Гораздо проще для понимания вот такое: БП>
[Storage(ViewState), DefaultValue(0)] public PageNo : int { get; private set;}
БП>Тут совершенно ясно, что происходит и лушние детали в глаза не лезут.
Это какйо-то странный синтаксис. У тебя проблема предметной области, ну, и нечего придумывать универсальное решение. Сделай макрос ViewState с параметром defaultValue. В нем и добавишь все что тебе нужно. Выгдядеть будет так:
[ViewState(0)] public PageNo : int { get; private set; }
Автосвойства тут вообще не причем. Макрос все должен делать сам.
В общем, потратил 20 минут наклепал этот макрос:
using Nemerle;
using Nemerle.Compiler;
using Nemerle.Collections;
using Nemerle.Utility;
using Nemerle.Compiler.Parsetree;
using System;
namespace MacroLibrary2
{
[MacroUsage(MacroPhase.BeforeTypedMembers, MacroTargets.Property, Inherited = true)]
macro ViewState(_ : TypeBuilder, propertyAst : ParsedProperty, defaulteValue)
{
when (!(propertyAst.Attributes %&& (NemerleAttributes.Abstract | NemerleAttributes.Extern)))
match (propertyAst.get, propertyAst.set)
{
| (Some(PT.ClassMember.Function(_, _, FunBody.Abstract) as getr),
Some(PT.ClassMember.Function(_, _, FunBody.Abstract) as setr)) =>
def ctx = Nemerle.Macros.ImplicitCTX();
ctx.Env.Manager.MacroColors.PushUseSiteColor();
try
{
getr.Body = <[
def val = $("ViewState" : usesite)[$(propertyAst.Name : string)];
if (val == null) $defaulteValue else (val :> $(propertyAst.ty))
]>;
setr.Body = <[ $("ViewState" : usesite)[$(propertyAst.Name : string)] = value ]>;
}
finally { ctx.Env.Manager.MacroColors.PopColor(); }
| _ => Message.Error(propertyAst.Location, "Property should have empty getter and setter!")
}
}
}
Использование:
using System;
using Nemerle.Collections;
using System.Console;
using Nemerle.Utility;
using MacroLibrary2;
public class A
{
ViewState : System.Collections.Hashtable = System.Collections.Hashtable();
[ViewState(0)]
public Prop1 : int { get; set; }
[ViewState("<empty>")]
public Prop2 : string { get; set; }
}
module Program
{
Main() : void
{
def a = A();
WriteLine($"a.Prop1=$(a.Prop1)");
WriteLine($"a.Prop2=$(a.Prop2)");
a.Prop1 = 123;
a.Prop2 = "test";
WriteLine($"a.Prop1=$(a.Prop1)");
WriteLine($"a.Prop2=$(a.Prop2)");
Write("..."); _ = ReadLine();
}
}
Что касается 20 минут. Перед этим конечно пару месяцев нужно потратить на исследование макросистемы, а лушче еще годик на изучение компилятора. Тогда за 20 минут легко такие вещи делаются. Без этих знаний конечно будет не просто. Но думаю, что после того как я допишу цикл статей по макросам — это будет доступно всем кто умеет читать по русски.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Пока Янус обновлялся, подумал, что переусложнил. Так как используется переключение в цвета области использования (PushUseSiteColor()), то все имена и так будут браться из области использования, так что вместо:
$("ViewState" : usesite)
можно просто писать
ViewState
Вот упрощенный вариант.
when (!(propertyAst.Attributes %&& (NemerleAttributes.Abstract | NemerleAttributes.Extern)))
match (propertyAst.get, propertyAst.set)
{
| (Some(PT.ClassMember.Function(_, _, FunBody.Abstract) as getr),
Some(PT.ClassMember.Function(_, _, FunBody.Abstract) as setr)) =>
def ctx = Nemerle.Macros.ImplicitCTX();
ctx.Env.Manager.MacroColors.PushUseSiteColor();
try
{
getr.Body = <[
def val = ViewState[$(propertyAst.Name : string)];
if (val == null) $defaulteValue else (val :> $(propertyAst.ty))
]>;
setr.Body = <[ ViewState[$(propertyAst.Name : string)] = value ]>;
}
finally { ctx.Env.Manager.MacroColors.PopColor(); }
| _ => Message.Error(propertyAst.Location, "Property should have empty getter and setter!")
}
}
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Пока Янус обновлялся, подумал, что переусложнил. Так как используется переключение в цвета области использования (PushUseSiteColor()), то все имена и так будут браться из области использования, так что вместо: VD>
VD>$("ViewState" : usesite)
VD>
VD>можно просто писать VD>
VD>ViewState
VD>
Нет, предыдущий макрос был как раз лучше. Осталось только оформить "ViewState" параметром и будет именно то что нужно. А иначе для Session/Application и что там ещё есть придётся новые макросы городить.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[10]: Добавил поддержку auto-property (как в C# 3.0)
тему уже пора переносить в flame wars ;)
VD>Автосвойства — это продуманное решение. Продуманное не по одному критерию "ах какая приятная рюшечка", а по массе критериев, от совестимости со старым кодом, до локаничности и безопасности.
если бы этот ответ был сразу, никаких споров не возникло бы.
я верю в маудрость разработчиков Nemerle ;) но решать за меня, что мне надо — не стоит.
VD>Пока что я вижу четкую связь между уровнем программиста и желанием налепить решений вроде свойств доступных только для записи
а вот переход на личности с прозначными намёками — это лишнее. (не первый раз уже).
вас (немерлистов) и так слишком мало чтобы вот так из-за эмоций распугивать интересующихся людей.
раз в три года и goto пригождается — поговорим о программистах, которые не предали анафеме goto? :)
за все годы write-only-свойство использовал всего один раз, но там оно было очень кстати.
Здравствуйте, Блудов Павел, Вы писали:
БП>Нет, предыдущий макрос был как раз лучше. Осталось только оформить "ViewState" параметром и будет именно то что нужно.
Можешь конечно оформить, но это уже нагромождение получится. В прочем, это твои прикладные проблемы.
БП>А иначе для Session/Application и что там ещё есть придётся новые макросы городить.
Декомпозицию еще никто не отменял. Код макроса можно вынести в фукнцию, а имя свойства передавать в качестве параметра. Получится 3 макроса вида:
Если нам не помогут, то мы тоже никого не пощадим.
