Здравствуйте, 9kpm66, Вы писали:
L>>А вы в курсе что такое свойство с точки зрения CLR?
9>А вы в курсе что такое CLR с точки зрения линуксоида?
Это зависит от определения данного термина. Если рассматривать "линуксойда" как недалекого фаната, то наверно что-то очень неприятное и плохое. Если это образованный и рассудительный человек, то термин будет означать тоже самое, что и для остальных — ядро виртуальной машины. Тоже самое что ява-ратнайм.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
N>А в поле, типом которого является value-тип, легко можно поменять отдельное поле этого value-типа (но это можно было бы эмулировать и для свойств).
На мой взгляд, даже не "можно", а "нужно".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
N>>А в поле, типом которого является value-тип, легко можно поменять отдельное поле этого value-типа (но это можно было бы эмулировать и для свойств).
VD>На мой взгляд, даже не "можно", а "нужно".
Здравствуйте, nikov, Вы писали:
N>>>А в поле, типом которого является value-тип, легко можно поменять отдельное поле этого value-типа (но это можно было бы эмулировать и для свойств).
VD>>На мой взгляд, даже не "можно", а "нужно".
N>Очень может быть. Кстати, как в Nemerle с этим?
Как ты понимаешь — это проблема не языка, а платформы. В прочем, можно подумать над тем, чтобы выявлять такие случае и автоматически переписывать код.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
N>>>>А в поле, типом которого является value-тип, легко можно поменять отдельное поле этого value-типа (но это можно было бы эмулировать и для свойств). VD>>>На мой взгляд, даже не "можно", а "нужно". N>>Очень может быть. Кстати, как в Nemerle с этим?
VD>Как ты понимаешь — это проблема не языка, а платформы. В прочем, можно подумать над тем, чтобы выявлять такие случае и автоматически переписывать код.
Честно говоря, я не понимаю, как платформа может догадаться, что изменение в значении, возвращенном геттером свойства, надо как-то транслировать обратно в то место, откуда его взяли, если компилятор явно не сгенерирует соответствующий код. В C# выбрано простое решение: выдавать ошибку компиляции в таких случаях. Подозреваю, что сейчас Nemerle не выдает ошибку, а молча игнорирует изменения.
Здравствуйте, VladD2, Вы писали:
VD>Этот вопрос был поставлен уже давно. Только звучал он немного по другому — "Зачем нужны циклы если есть рекурсивные функции, функции высшего порядка и макросы?".
А макросы сюда каким боком относятся? Первых 2х недостаточно?
now playing: Massive Attack — Bulletproof Love (feat. Guy Garvey) (Christoff Berg Remix)
Здравствуйте, nikov, Вы писали:
N>Честно говоря, я не понимаю, как платформа может догадаться, что изменение в значении, возвращенном геттером свойства, надо как-то транслировать обратно в то место, откуда его взяли, если компилятор явно не сгенерирует соответствующий код. В C# выбрано простое решение: выдавать ошибку компиляции в таких случаях.
Есть четкий паттерн:
1. Взяли значение из свойства.
2. Изменили это значение.
3. Никуда не положили.
N>Подозреваю, что сейчас Nemerle не выдает ошибку, а молча игнорирует изменения.
Ну, как сказать. Вот такой код:
[Record]
struct A
{
public mutable X : int;
}
[Record]
class B
{
public Prop : A { get; set; }
}
def b = B(A(123));
b.Prop.X = 654;
System.Console.WriteLine(b.Prop.X);
Выдает:
x.n:14:1:14:15: error: this expression is not a proper lvalue: cannot load value type address
Правда, нашелся баг. Вот такой вариант:
[Record]
struct A
{
public mutable X : int;
}
[Record]
class B
{
public Prop : A { get; set; }
}
def b = B(A(123));
b.Prop.X++;
System.Console.WriteLine(b.Prop.X);
Успешно компилируется, но приводит к выдачи весьма странного рантайм-исключения:
====WARNING====
You have probably encountered known bug VSW:137474, which fires
when System.EnterpriseServices.Thunk.Proxy::LazyRegister is jitted.
The bug often shows up in tests under ManagedServices\Interop.
VSW:137474 has been fixed, but the fix has not yet been propagated
to Lab21S. Please check to see if the assert/AV occurs while
compiling LazyRegister before entering a new bug for this failure.
===============
Вскрытие показало, что генерируется следующий код (рефлетро-C#):
B b = new B(new A(0x7b));
ref A prop = b.Prop;
prop.X++;
Console.WriteLine(b.Prop.X);
Здравствуйте, EvilChild, Вы писали:
VD>>Этот вопрос был поставлен уже давно. Только звучал он немного по другому — "Зачем нужны циклы если есть рекурсивные функции, функции высшего порядка и макросы?".
EC>А макросы сюда каким боком относятся? Первых 2х недостаточно?
А макры позволяют придать нужный синтаксис к имеющимся средствам.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>На мой взгляд было бы интересно обсудить какие просчеты были сделаны в виртуальных машинах и языках.
Ну вот из свеженького — в FW 4.0, в mscorlib добавлены интерфейсы IObservable/IObserver, что, на мой взгляд, является фактически признанием ошибочности внесения в CLR событий. Осталось слегка подрихтовать C#/VB, чтобы можно было использовать оператор += и синтаксис VB, и события станут полностью бесполезными . А там можно заодно и делегаты приговорить.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
Здравствуйте, MxKazan, Вы писали:
PD>>А когда вы его declare не так как в этом example, то вам придется это поле создать вручную и в свойстве set в него что-то занести. MK>И тем не менее, я привел пример, когда поля в классе нет, если абстрагироваться от того, что генерит компилятор. Это поведение (генерацию поля) в теории можно легко изменить, если из языка устранить само понятие поля. Ну т.е. сделать что-то вроде свойств хранилищ (бывшие поля) и свойств с аксессорами
В принципе, конечно, ты прав, правда, это уже будет не .Net как она есть сейчас, а нечто иное. Можно и дальше пофантазировать — хранение всех этих свойств (бывших полей) в БД, полностью спроецированной в оперативную память.
Здравствуйте, VladD2, Вы писали:
PD>>М-да... Судя по всему, следующий вопрос (через пару лет) будет — зачем нужны циклы, если есть LinQ
VD>Этот вопрос был поставлен уже давно. Только звучал он немного по другому — "Зачем нужны циклы если есть рекурсивные функции,
Реализация рекурсивной функции при нынешней архитектуре есть неявный цикл на стеке.
Здравствуйте, VladD2, Вы писали:
VD>Я как-то уже думал на эту тему и пришел к выводу, что в языке можно было бы избавиться от лишней абстракции. Поля можно было бы переставлять как свойства с двумя публичными эксесорами. Это упростило бы язык и сделало бы более легким использование рефлексии (поля попросту можно было бы игнорировать во многих случаях).
Я бы проще это сформулировал. ИМХО реализация дефолтных свойств как она есть в C# сделана не с той стороны. Вместо того, чтобы делать свойства с теневым полем, надо было сделать поля с автоматическим созданием свойства. Есть, к примеру, поле string name — автоматом создается свойство string Name с простейшей реализацией. Не нравится — напиши его сам. Ну и для полносты картины атрибут [Nonpropertable] запрещающий это либо для всего класса, либо для конкретного поля.
VD>На мой взгляд было бы интересно обсудить какие просчеты были сделаны в виртуальных машинах и языках. И то как должны выглядеть более совершенные ВМ и ЯП.
Это не просчеты. Это просто развитие языка в конкретной исторической обстановке. Не могли быть классы в Фортране и раннем Бейсике, качественная рефлексия в С++ и идеи ФП — в C# 1.0. Всему свое время.
Здравствуйте, 9kpm66, Вы писали:
9>Здравствуйте, Lexxpin, Вы писали:
L>>А вы в курсе что такое свойство с точки зрения CLR?
9>А вы в курсе что такое CLR с точки зрения линуксоида?
А вы в курсе, что такое линуксоид с точки зрения свойства?
Здравствуйте, Pavel Dvorkin, Вы писали:
VD>>На мой взгляд было бы интересно обсудить какие просчеты были сделаны в виртуальных машинах и языках. И то как должны выглядеть более совершенные ВМ и ЯП.
PD>Это не просчеты. Это просто развитие языка в конкретной исторической обстановке.
Павел, ну ты же сам не так давно рассуждал на тему о влиянии личностей на развитие индустрии. Есть мнение, что это развитие не столько языка, сколько людей, принимающих участие в его разработке. Если бы C# проектировался не командой Хейлсберга, а, скажем, Пейтоном-Джонсом и К, то сейчас бы речь шла о том, что не могло бы быть императивщины в первом шарпе
Я так понимаю, что проблема в необходимости, практически на каждом очередном витке этой "эволюции", поиска командой ответа на вопрос "а что делать с тем, что уже есть?" (т.е. обратной совместимости), а также о том, что шарп сильно завязан на среду выполнения (ну или наоборот несмотря на CLI, тут я хз, что первично), т.е. нужно принимать во внимание не только пожелания и планы архитекторов самого языка. И если бы упомянутые просчеты не были допущены изначально, то "развитие языка в конкретной исторической обстановке" протекало бы куда более динамично.
PD>Не могли быть классы в Фортране и раннем Бейсике,
Не потому ли, что идеи ООП если вообще и имели место в моменты рождения этих языков, то где-то ближе к зародышевому состоянию?
PD>качественная рефлексия в С++
А в С++ уже есть качественная рефлексия?
PD>и идеи ФП — в C# 1.0. Всему свое время.
А вот ФП как парадигма, в момент рождения шарпа, была уже более чем сформировавшейся (ибо она старше бейсика, AFAIK). Т.о. причины отсутствия ее поддержки в шарпе отличаются от причин отсутствия ООП в бейсике и фортране
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я бы проще это сформулировал. ИМХО реализация дефолтных свойств как она есть в C# сделана не с той стороны. Вместо того, чтобы делать свойства с теневым полем, надо было сделать поля с автоматическим созданием свойства. Есть, к примеру, поле string name — автоматом создается свойство string Name с простейшей реализацией. Не нравится — напиши его сам. Ну и для полносты картины атрибут [Nonpropertable] запрещающий это либо для всего класса, либо для конкретного поля.
Кошмар.
PD>Это не просчеты. Это просто развитие языка в конкретной исторической обстановке. Не могли быть классы в Фортране и раннем Бейсике, качественная рефлексия в С++ и идеи ФП — в C# 1.0. Всему свое время.
Идеи ФП в С# 1 может и не могли быть, но причины этого не технические.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Я бы проще это сформулировал. ИМХО реализация дефолтных свойств как она есть в C# сделана не с той стороны. Вместо того, чтобы делать свойства с теневым полем, надо было сделать поля с автоматическим созданием свойства. Есть, к примеру, поле string name — автоматом создается свойство string Name с простейшей реализацией. Не нравится — напиши его сам. Ну и для полносты картины атрибут [Nonpropertable] запрещающий это либо для всего класса, либо для конкретного поля.
AVK>Кошмар.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Pavel Dvorkin, Вы писали:
VD>>>На мой взгляд было бы интересно обсудить какие просчеты были сделаны в виртуальных машинах и языках. И то как должны выглядеть более совершенные ВМ и ЯП.
PD>>Это не просчеты. Это просто развитие языка в конкретной исторической обстановке.
KV>Павел, ну ты же сам не так давно рассуждал на тему о влиянии личностей на развитие индустрии. Есть мнение, что это развитие не столько языка, сколько людей, принимающих участие в его разработке. Если бы C# проектировался не командой Хейлсберга, а, скажем, Пейтоном-Джонсом и К, то сейчас бы речь шла о том, что не могло бы быть императивщины в первом шарпе
KV>Я так понимаю, что проблема в необходимости, практически на каждом очередном витке этой "эволюции", поиска командой ответа на вопрос "а что делать с тем, что уже есть?" (т.е. обратной совместимости), а также о том, что шарп сильно завязан на среду выполнения (ну или наоборот несмотря на CLI, тут я хз, что первично), т.е. нужно принимать во внимание не только пожелания и планы архитекторов самого языка. И если бы упомянутые просчеты не были допущены изначально, то "развитие языка в конкретной исторической обстановке" протекало бы куда более динамично.
Вполне согласен. Но , сказав, "просто развитие языка в конкретной исторической обстановке", я вообще-то ничего плохого сказать не хотел.
PD>>Не могли быть классы в Фортране и раннем Бейсике,
KV>Не потому ли, что идеи ООП если вообще и имели место в моменты рождения этих языков, то где-то ближе к зародышевому состоянию?
May be. А may и not be. Я те времена хорошо помню. Не те проблемы нас занимали, и не те задачи мы решали. А задачи были более математические, вычислительные. Там алгоритмы первенствуют, а не организация. А ООП все же скорее организация, чем алгоритм. Во всяком случае, все, что можно сделать с ООП , можно сделать и без него (доказательство простое — можно написать на асме, а там нет ООП), а вот без алгоритма никакое ООП не поможет. Просто время не пришло.
PD>>качественная рефлексия в С++
KV>А в С++ уже есть качественная рефлексия?
Так я и говорю же — не могла.
PD>>и идеи ФП — в C# 1.0. Всему свое время.
KV>А вот ФП как парадигма, в момент рождения шарпа, была уже более чем сформировавшейся (ибо она старше бейсика, AFAIK). Т.о. причины отсутствия ее поддержки в шарпе отличаются от причин отсутствия ООП в бейсике и фортране
Почему отличаются ? Ты же сам говоришь — во времена царствия Фортрана ООП уже было. Но не было нужным. Так же как и ФП в C# 1.0.
Здравствуйте, Pavel Dvorkin, Вы писали:
VD>>Я как-то уже думал на эту тему и пришел к выводу, что в языке можно было бы избавиться от лишней абстракции. Поля можно было бы переставлять как свойства с двумя публичными эксесорами. Это упростило бы язык и сделало бы более легким использование рефлексии (поля попросту можно было бы игнорировать во многих случаях).
PD>Я бы проще это сформулировал. ИМХО реализация дефолтных свойств как она есть в C# сделана не с той стороны. Вместо того, чтобы делать свойства с теневым полем, надо было сделать поля с автоматическим созданием свойства. Есть, к примеру, поле string name — автоматом создается свойство string Name с простейшей реализацией. Не нравится — напиши его сам. Ну и для полносты картины атрибут [Nonpropertable] запрещающий это либо для всего класса, либо для конкретного поля.
http://nemerle.org/Accessor_macros
Вот только автосвойства по жизни удобнее.
VD>>На мой взгляд было бы интересно обсудить какие просчеты были сделаны в виртуальных машинах и языках. И то как должны выглядеть более совершенные ВМ и ЯП.
PD>Это не просчеты. Это просто развитие языка в конкретной исторической обстановке. Не могли быть классы в Фортране и раннем Бейсике, качественная рефлексия в С++ и идеи ФП — в C# 1.0. Всему свое время.
Есть и просчеты. АВК тут правильно заметил, что влеплять события и делегаты рантайм было не верно. Нужны были более базовые вещи — функциональные типы и набор стандартных интерфейсов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Зачем нужны циклы если есть рекурсивные функции
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Реализация рекурсивной функции при нынешней архитектуре есть неявный цикл на стеке.
А какая разница, как это реализуется, неужели от этого поменяется суть Впрочем, посмотрим, как...
Не знаю, что понимается под нынешней архитектурой... на примере x86
mov eax, 5
@@: nop ;
dec eax ; тело цикла
jnz @b ;
В ассемблере нет функций или процедур, есть подпрограммы — участки кода, предназначенные для многократного вызова. В примере выше такой подпрограммой является команды обозначенные анонимной меткой @@. Вызывавется она (то есть, её адрес загружается в указатель инструкций IP) командой условного перехода jnz. Выход из подпрограммы осуществляется этой же командой, естественным инкрементом IP. Это возможно, поскольку подпрограмма вызывается только из одного места (поэтому же нет нужды использовать для вызова call, сохраняя в стеке адрес возврата).
Цикл — это просто короткое название вышеописанного рекурсивного вызова, один из частных случаев. Термин придумали, что бы проще понять рекурсию (т.к. для этого можно не понимать рекурсию).
Еще один частный случай (реализации) рекурсивного вызова:
Можно придумать еще несколько, включая комбинации.
To zen it, следует забыть "ассемблер" Iczelion'а и Зубкова, с его С-шной идеологией и регламентированными конвенциями вызовов.
Параметры в подпрограмму могут передаваться например так:
call foo
dd 1
dd 2
call boo
Или так:
mov ebp, @f
jmp foo
dd 1
dd 2
@@:
В последнем случает стек и для сохранения адреса возврата не используется. Да и что такое стек, адресуемая регистром общего назначения esp память? А почему именно esp, только потому, что в CISC x86 есть удобные команды для этого? Вот в самом первом примере стек значений от 5 до 0 реализован всего на одном регистре eax без посторонней памяти.
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Павел, ну ты же сам не так давно рассуждал на тему о влиянии личностей на развитие индустрии. Есть мнение, что это развитие не столько языка, сколько людей, принимающих участие в его разработке. Если бы C# проектировался не командой Хейлсберга, а, скажем, Пейтоном-Джонсом и К, то сейчас бы речь шла о том, что не могло бы быть императивщины в первом шарпе
в Войне и мiре есть рассуждение о влиянии личности на историю. говоря кратко, значительно повлиять на историю может только человек, направление деятельности которого совпало с исторически обусловленным ходом развития. не мог spj оказаться во главе этого проекта — ибо MS интересовал коммерческий успех детища Х., а не теоретические изыски хаскеллеров. но если бы даже и оказался — созданный им продукт не пошёл бы у программистов, и ms проиграла бы в противостоянии сану, только и всего
в середине 90-х никто, включая наверно и самих spj и вадлера, не мог представить что через 10 лет процессоры таки станут многоядерными и это усилит интерес к фп так что оно станет естественной заменой ооп. а представь себе что этого бы не произошло и вместо фп стало популярно лп и ты точно так же сидел бы здесь переживвал что ms не догадалось поставить во главе своего проекта ковалевского
. А там можно заодно и делегаты приговорить.
