diadiavova, надо будет написать Хейльсбергу и спросить у него )))

А это правда так важно?

Это сообщение отредактировал(а) diadiavova - 4.11.2008, 02:06

Как минимум интересно...

А вот кстати:
Язык F# - фа-диез
И что после этого думать?

diadiavova, J# тогда это что?

Ява
Свою реализацию javascript они назвали jscript, логично, что, стырив яву, они придерживались той же логики. А диез добавили, чтобы показать, что их ява круче 

Добавлено через 2 минуты и 16 секунд
Кроме того, имя было неправильное, поэтому язык долго не прожил

Добавлено через 4 минуты и 27 секунд
И кстати: если C# выше С на пол-тона, то F# - выше C# на целую кварту.

Не...я в смысле - это у нас чтоли Соль-диез?...
Не...не правильно это, язык программирования называть музыкальным термином...надо разграничивать...

з.ы. ладно...это уже полный оффтопик...
по топику могу только сказать, что согласен с теми, кто утверждает, что виртуальные по умолчанию методы из джавы(явы, как угодно) кроют потенциальную опасность, и, поэтому, невиртуальность по умолчанию, как это сделано в C# является плюсом...

Соль-диез будет G#. Не удивлюсь если и такой язык появится.


Трудно говорить, о таких вещах, как о плюсах или минусах. Дело привычки. Просто можно было какое нибудь ключевое слово придумать для всего класса, которое меняло бы умолчания, здесь варианты есть, да кто знает - может и придумают что-то в этом роде. 

На мой взгляд, музыканты ни причём. Даже американские немузыканты воспринимают название языка как "Си-диез". Они могут не знать, что "Си" означает ещё и ноту, а думать, что речь идёт о языке Си.

Добавлено через 8 минут и 58 секунд

Это что, существенно меняет дело? Требования те же самые, один х... надо читать инструкцию. Твой идеальный мир, в котором этого можно не делать всё равно не прорисовывается.


Это уже чистейшая инстинуация с твоей стороны. Требования те же самые, элементы те же самые, предназначение то же самое, значит и вероятность прочесть инструкцию та же самая. 


От того, что ты это сказал, оно так не стало 


Я не понял, почему это ты себе очко записал? Это абстрактное рассуждение с тем же успехом можно записать и на мой счёт.


А я где-то утверждал, что что есть как?


Разработчик железобетона предназначал его для изготовления цветочных горшков. Прикинь, что бы мы сейчас делали, если бы у него был в распоряжении C# для реальности?

Добавлено через 13 минут и 58 секунд

Это говорится в англо-русском словаре, в статье про слово "шарп", которое переводится, как "диез". Странно, что они говорят "си-шарп", но не имеют в виду диез, потому что тогда почему они говорят именно так?

Ну это претензия к Микрософту.

Добавлено через 1 минуту и 32 секунды
http://en.wikipedia.org/wiki/C_Sharp_(prog...)#Language_name

Нет, не те же. Для наследования от твоего воркера надо прочитать документацию по всем его функциям. Для использования MS-ового - только требования к обработчику события. Ты разницу между 1 статьей и полной документацией чувствуешь? Для дизайна MS не нужны виртуальные по умолчанию функции, даже наследование не нужно. Для твоего - надо обязательно сделать новый класс, и изучить всю документацию по базовому классу.

Есть галочка threat warning as errors. Которую принято включать  Warning - это когда даже компилятор видит что программист сморозил потенциально опасную хрень. Не влезай - убьет - warning, но его ты не игнорируешь обычно.
А представь что разрабочик глины предназначал ее для горшков. Один раз сделал ее чуть прочнее, какой-то чудак сделал из нее небоскреб, и с тех пор разрабочику глины приходится делать ее с учетом, что из нее будут лепить небоскребы. 
Наследование и виртуальные функции - не единственный способ расширяемости.

Вообще, наследование не от классов фреймворка - очень редко используемая вещь. Возьми, например, среднее web-приложение. Плоская иерархия классов-страниц, плоская иерархия контроллеров, плоская иерархия сервисов в BL, плоская иерархия объектов домена. Куча невирутальных функций. Основной упор - на реализацию интерфейсов, чтобы IoC работал. В win - та же самая картина. 90% классов не объявляют новые виртуальные функции и не переопределяют существующие. И вроде никто на проблемы с расширяемостью не жалуется. Нужно еще классы сделать sealed по умолчанию - потому что при написании классов никто обычно не думает что будет при наследовании. Очень сомневаюсь, что ты всегда думаешь о последствиях override-а.
Ты утверждал что практически любой метод можно сделать виртуальным без последствий. Это подразумевает что создающий наследника знает что делает метод родителя, и как именно он это делает. Или всегда может корректно переопределить его без знаний о деталях реализации этого метода в родителях. Т.к. телепаты пока не появились, то скорее - первое.

Это сообщение отредактировал(а) PashaPash - 4.11.2008, 11:13

В Америке существует два способа именования нот. Одно - международное(как у нас), оно почти не используется; другое происходит от английского названия латинских букв, которыми принято обозначать ноты(за одним небольшим исключением, происходящим от того, что американская система немного отличается от классической, это касается нот си и си-бемоль). Поэтому если сказать американцу си-шарп, он скорее всего подумает, что речь идёт именно о ноте.

А статья


порадовала. Оказывется есть ест ещё язык A#. То есть семейство "музыкальных" языков пополнилось ещё и ля-диезом   

Это сообщение отредактировал(а) diadiavova - 4.11.2008, 13:27

Эту разницу ты создал. 

Обработчик события DoWork -- это то, что у меня абстрактный метод SpecificWork. Собираясь его реализовать в наследнике, я должен буду прочесть к нему инструкцию. И там увижу почти тот же текст, что и в инструкции к Микрософтовскому воркеру. В частности, у себя в инструкции я увижу, что нужно проверять ShouldStop, а у Микрософта, что нужно проверять CancellationPending. Точно так же, как у Микрософта я могу захотеть написать обработчик RunWorkerCompleted и тогда прочту к нему инструкцию, так же и у меня я могу захотеть реализовать Done и тогда прочту инструкцию к нему.

Короче, те же яйца, вид сбоку. Где ты там видишь какую-то разницу, ума не приложу. 


Выдумываешь.


Это не голословное утверждение, а вывод на основе опыта программирования на Джава. Сообщество накопило, наверное, миллионы человеко-часов. Ты понимаешь, поэтому, что все жутчайшие выводы, которые ты сейчас сделаешь -- это борьба с ветряными мельницами?

Я же предлагаю рассуждать разумно. Если виртуальность всех функций и содержит какие-то недостатки, то они ТОНКИЕ. Нет такого, как пишешь ты. Или как diadiavova написал, что он не любит работать, когда сидишь и не знаешь, что делают методы, мол, якобы, это следует из виртуальности. Не так это. Не следует. 

Я не писал, что не люблю. 
А что следует из виртуальности, если не то, что в производном классе функция будет делать неизвестно что?
===============
Тут мне ещё вот какая мысля пришла в голову. Ну ладно, если мы пишем абстрактный класс. В нём по-идее сильно завязывать одно на другом - плохо, и надо сводить такие зависимости к минимуму.
Но ведь наследуются не только абстрактные классы. Я могу писать класс под определённые нужды. В нём естественно я и не очень расчитываю на то, что что-то будет переопределено, но возможность такую оставляю, на случай если кому-то надо будет расширить мой класс.

В такой ситуации по-моему вполне естественно что я предоставляю потенциальному(!) наследователю доступ только к тем элементам, которые расчитаны на то, что их могут переопределить. Всё остальное нужно для работы моего класса.

Кроме того: спорить о том, надо докуметировать классы или нет - бессмысленно. Другой вопрос: что лучше класс, требующий минимума документации, или такой, где про каждый метод надо будет объяснить все возможные последствия того или иного действия?

Покупая телевизор тоже инструкцию надо прочитать, но совсем не обязательно знать как он устроен для того, чтобы каналы переключать.

Поэтому и возникает вопрос, что лучше сделать максимально безопасный класс, или позволить делать с ним всё, но снабдить подробной инструкцией, объясняющей, почему этого делать
 нельзя.

Я же говорю: этот вывод элементарно опровергается практикой. Не могло бы быть на джаве написано столько качественных прог, если бы функции делали неизвестно-что.