Здравствуйте, AlexCab, Вы писали:
A>>пример приведи AC>
AC>//Определения
AC> Handle VAR
AC>//Работаем с окном
AC> Handle = GetWindowHandle()
AC> PostMessage(Handle)
AC> /*Делаем что то ещё с окном*/
AC>//Работаем с потоком
AC> Handle = GetThreadHandle()
AC> PostThreadMessage(Handle)
AC> /*Делаем что то ещё с потоком*/
AC> PostMessage(Handle) //<-- Ошибка типа
AC>
Думаю, если назвать переменные windowHandle и threadHandle, то понятность кода, по крайней мере, не ухудшится.
А где тут мутабельность переменной?
Здравствуйте, artelk, Вы писали: A>Думаю, если назвать переменные windowHandle и threadHandle, то понятность кода, по крайней мере, не ухудшится.
Это менее удобно при написании.
A>другой пример приведи
//Определения
Displayd VAR
//Показать заничение из функции "GetSomeVolum"
Displayd = GetSomeVolum() //Возвращает значение любого числового типа.
Displayd = Displayd + 5
Displayd = "Vol_of_GetSomeVolum+5:" + Displayd //Если в "Displayd" тип пользовательский и не описано приведение к char - будет ошибка при компиляции.
PrintF(Displayd) //Хотя в этом простом случае можно было би и так записать: PrintF(("Vol:" + (GetSomeVolum() + 5)))
//Показать заничение из функции "GetWindowHandle"
Displayd = GetThreadHandle()
/*Делаем что то с "Displayd"*/
PrintF(Displayd)
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
A>>Думаю, если назвать переменные windowHandle и threadHandle, то понятность кода, по крайней мере, не ухудшится. AC>Это менее удобно при написании.
У нормальных людей есть IDE и им пофиг.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
А как быть с таким:
SomeFunction(bool b)
{
S VAR //Локальная перменная
//Какой то код
S = 0 //Присваевание числа
if(b)
S = "С" //Присваевание символа
OtherFunction(S);
}
Здравствуйте, VladD2, Вы писали:
VD>Это отговорки.
Нет дело в очерёдности, на данном этапе работы ещё рано.
VD>В наличии меньшего количества переменных нет ничего хорошего. На любом ФЯ можно писать почти совсем без переменных. Но это не значит, что код будет хорошо читаемым. VD>Так что не надо экономить на спичках. Если переменные нужны, то смело вводи их.
Только если они действительно нужны.
VD>А уж повторное использование имен — это просто глупость.
Согласен.
VD>Ничего мы не знаем. Скорее всего в твоем коде будет море багов и найти их (из-за того, что ты сделал язык дырявым) будет очень не просто.
Свобода vs Порядок — извечное противостояние.
VD>Для изменяемых переменных это опасно.
Для не изменяемых тоже, по значению:
def s = 0
//Какой то большой код в котором где то есть "def s = 1"
/*Код рассчитывающий что s = 0*/
По типу ошибка слоится компилятором в обоих случаях.
Хотя не спорю при более строгих правилах ошибку допустить сложнее(найти в тексте определение проще чем присваивание).
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
VD>>Ничего мы не знаем. Скорее всего в твоем коде будет море багов и найти их (из-за того, что ты сделал язык дырявым) будет очень не просто. AC>Свобода vs Порядок — извечное противостояние.
Это у тебя своеобразная такая свобода. Свобода получать удары током от оголенных проводов.
VD>>Для изменяемых переменных это опасно. AC>Для не изменяемых тоже, по значению: AC>
AC>def s = 0
AC>//Какой то большой код в котором где то есть "def s = 1"
AC>/*Код рассчитывающий что s = 0*/
AC>
AC>По типу ошибка слоится компилятором в обоих случаях.
Это теоретические домыслы. На практике никаких проблем нет. Переменные случайно не вводятся.
AC>Хотя не спорю при более строгих правилах ошибку допустить сложнее(найти в тексте определение проще чем присваивание).
Особенно когда тебе помогает IDE. В Немерле когда подводишь мышь к имени, то всего его использования подсвечиваются розовеньким, а определение синеньким. Так что сразу видно, где переменная определена и как используется.
В общем, меняй свои приоритеты, чтобы не заниматься велосиподостроением.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, любой, Вы писали: Л>А как быть с таким: Л> SomeFunction(bool b) Л> { Л> S VAR //Локальная перменная Л> //Какой то код Л> S = 0 //Присваевание числа Л> if(b) Л> S = "С" //Присваевание символа Л> OtherFunction(S); Л> }
Если я правильно понял то "S = "С"" а может и не выполнится в зависимости от значения в "b",
так как тип аргументов "OtherFunction"(как и всех остальных функций) строго определён компилятор сможет проверить корректность
типа содержимого "S" и если это возможно привести к нужному типу.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, VladD2, Вы писали: AC>>Свобода vs Порядок — извечное противостояние. VD>Это у тебя своеобразная такая свобода. Свобода получать удары током от оголенных проводов.
Напишу потому как знаю не понаслышке, доступ к "оголённым проводам" даёт несравнимо больше свободы чем доступ только к панели оператора.
AC>>По типу ошибка слоится компилятором в обоих случаях. VD>Это теоретические домыслы.
Truth.
AC>>Хотя не спорю при более строгих правилах ошибку допустить сложнее(найти в тексте определение проще чем присваивание). VD>Особенно когда тебе помогает IDE. В Немерле когда подводишь мышь к имени, то всего его использования подсвечиваются розовеньким, а определение синеньким. Так что сразу видно, где переменная определена и как используется.
Взгляд с этой точки зрения сводит на нет преимущества явного определения и константности переменных. Что мешает IDE интерактивно подсказать
тип значения находящегося в переменной в данный момент(например сразу после ввода имени, при написании текста программы).
VD>В общем, меняй свои приоритеты, чтобы не заниматься велосиподостроением.
Как велосипедостроитель велосипедостроителю, признайте ведь это интересно
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Напишу потому как знаю не понаслышке, доступ к "оголённым проводам" даёт несравнимо больше свободы чем доступ только к панели оператора.
А, ну-ну.
AC>Взгляд с этой точки зрения сводит на нет преимущества явного определения и константности переменных. Что мешает IDE интерактивно подсказать тип значения находящегося в переменной в данный момент(например сразу после ввода имени, при написании текста программы).
Чтобы IDE что-то подсказала ей нужно иметь какие-то ограничения которые она смогла бы проверить. А если ограничений нет, то и подсказать она ничего не может. Мы же можем засунуть в переменную все что угодно!
VD>>В общем, меняй свои приоритеты, чтобы не заниматься велосиподостроением. AC>Как велосипедостроитель велосипедостроителю, признайте ведь это интересно
Интересно делать новое. А переизобретать старое не очень интересно. Про него можно просто узнать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Чтобы IDE что-то подсказала ей нужно иметь какие-то ограничения которые она смогла бы проверить.
Возвращаясь к первому посту, достаточно ли в этом случае ограничений, и если нет почему?
VD>Мы же можем засунуть в переменную все что угодно!
В данном случае, только значения любого типа.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Спасибо, примерно так я и думал, компилятор может построить граф функции и обойти его проверяя типы, в случае неопределённости AC>например: AC>
AC>IF /*Какоето условие*/
AC> / \
AC> S = "C" S = 0
AC> \ /
AC> X = S + 1
Картинка характерная . Посмотрите Static single assignment form. Достаточно много компиляторов используют подобное представление, правда, не для вывода типов.
Здравствуйте, AlexCab, Вы писали: A>>Думаю, если назвать переменные windowHandle и threadHandle, то понятность кода, по крайней мере, не ухудшится. AC>Это менее удобно при написании.
Главное — удобство при чтении. Написание — очень редкое событие в жизни кода. Ради него можно немножко и постараться.
Код, использующий одну переменную в разных смыслах, вы бы впоследствии опубликовали на тематическом форуме с вопросом "Много ли времени ушло на понимание того, что метод делает".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AlexCab, Вы писали:
AC>Примерно так, но и для изменяемых переменных, и без необходимости переопределять(более опасно, более удобно).
Без необходимости переопределять боюсь в статическом жестко типизированном языке не получится, а вот с мутабельными
переменными в ML-образных языках без проблем:
open Printf;;
let s = ref 0;; (* s мутабельная переменная типа int *)
s := 10;; (* присваиваем *)
printf "s = %d\n" !s;;
let s = ref"test";; (* s теперь мутабельная переменная типа string *)
s := "Ok";; (* присваиваем *)
printf "s = %s\n" !s;;
Здравствуйте, artelk, Вы писали:
A>Одно и то же имя имеет разный смысл в зависимости от позиции внутри функции. Это усложняет понимание. A>Переопределение удобно только если тип меняется, а смысл переменной остается. A>Приходит, например, в функцию строковой параметр itemCount. Ты знаешь, что там должно быть число. A>В начале ф-ии парсишь его и переопределяешь itemCount с типом int: A>
A>f(itemCount : string) : void
A>{
A> def itemCount = int.Parse(itemCount);
A> //тут используем уже как число
A>}
A>
A>Так да, удобно — чтобы лишние имена не плодить со всякими префиксами-постфиксами. A>Пример, конечно, не очень, но иногда не хватает подобной фичи.
Как раз ML'ный let-биндинг такое легко позволяет:
let f (itemCount:string) =
let itemCount:int = int_of_string itemCount in itemCount + 1;;
через 'let' переопределяем itemCount и после 'in' используем.
