Здравствуйте, VladD2, Вы писали:
A>>Потому что так не бывает, что я что-то пишу и никто в компании этого больше не понимает. Это не нормально. VD>Да ладно тебе. Вот исходники Булкита, например, никто кроме IT в полном объеме не понимают. Но ведь Булкит все же используют?
Но язык-то на котором он написан знают многие! Мы говорим о языке, а не о библиотеке. Для бизнеса это больший риск.
Здравствуйте, adontz, Вы писали:
A>Но язык-то на котором он написан знают многие! Мы говорим о языке, а не о библиотеке. Для бизнеса это больший риск.
Не, не знают. В любом проекте как не крути появляются собственные подязыки. Не поняв их понять реализацию нельзя. Скажем у IT применяется эмуляция паттерн-матчинга. Причем выглядит она жутко. Но без нее задача была бы совсем неподъемной. И чтобы понять его проект нужно понимать, что делает этот паттерн-марчинг.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Потому что так не бывает, что я что-то пишу и никто в компании этого больше не понимает. Это не нормально. VD>Да ладно тебе. Вот исходники Булкита, например, никто кроме IT в полном объеме не понимают. Но ведь Булкит все же используют?
Я сам там не всё понимаю, приходится каждый раз по-новой разбираться. Было бы всё это на Немерле, было бы гораздо проще и понятнее.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, adontz, Вы писали:
VD>>Парсер прогоняли на куче исходников. От Януса, до исходников дотнета. Вроде пашет.
A>Ну, это уже показатель.
Кстати, о парсере шарпа. Вот тут можно взять парсер на на основе АНТЛР-а.
Вот только для сборки нужна Ява и есть одна проблема. Для сравнения наш парсер в релизе работает примерно в 10 раз быстрее. И это при том что PegParser значительно гибче АНТЛР-а (например, рассчитан на динамическое расширение грамматики).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>В нем вместо параметров left и left указаны плэйсходеры — "_". Так как плэйсхолдеры сопоставляются со всем чем угодно (даже с null), то мы получим требуемый результат. VD>Кстати, Identifier — это не вариант, а простой класс. Так что "Identifier where(id="==")" — это поттерн-матчинг по объекту.
Ага, и поэтому Id с большой буквы? Имхо, в этом плохого ничего нет, наоборот понятно, что проверяется свойство Id. То, что Identifier с большой буквы тоже говорит о том, что это имя типа.
VD>Так вот того же самого эффекта можно добиться если вместо приведенного выше паттерна можно использовать вот такой:
VD>Понятно, что на вхождение варианта с тремя полями выигрыш неощутим, но если представить себе вхождение с десятью полями, то это становится удобно. Кроме того понято что происходит.
Спасибо, теперь понятно.
VD>Собственно с классами только такой синтаксис пока и доступен. Плюс надо еще ключевое слово where со скобками добавлять. VD>>>Да и сам объект может быть создан с помощью конструктора с использованием имен параметров. _FR>>И какие сложности будут тут? VD>Никаких, но будет видно что параметры в ПаскальКейсе.
в ПаскальКейсе только "Identifier" и "Id" — о каких параметрах речь? Непосредственно к вариантам класс "Identifier" отношения не имеет. То есть сейячас речь о Record-ах? Так там тоже поля получаются Почему нельзя сделать так же: пользователь указывает
[Record]
public class Identifier : Located
{
[Accessor] Id : string;
public override ToString() : string
{
id
}
}
а параметр конструктора называется "id"? А свойство — Id. (другое дело, если пользователь объявил два свойстьва: id и Id — тогда и параметра конструктора должно быть два в разном регистре. Это не сложно разрулить).
Дальше: в where(Id="==") "Id" — это параметр конструктора, тогда можно (то есть даже придётся) будет писать where(id="==") а если Id — это поле/свойство, то должно быть написано с большой буквы и "параметры в ПаскальКейсе" всё-таки будут отсутствовать.
_FR>>ОК, то есть дело не принципиальное в устройстве компилятора, а в традициях? ОК. VD>Да.
Тут разве что могу предложить принять точку зрения того, что данные традиции противоречат традициям дотнета.
_FR>>Теперь далее, к свойствам. Есть ли технические проблемы, требующие необходимость именно в полях в вариантах или это тоже лишь дань традиции? VD>Да. В варианта всегда описываются поля. Причем поле у которого не указан атрибут [RecordIgnore] автоматом попадает в конструктор. Вся суть вариантов в этом и заключается. Компилятор знает о соответствии полей параметрам конструктора и на основании этого знания позволяет описывать паттерны в виде конструкторов (возможно вложенных, и даже рекурсивных).
ИМХО, знание о том, как свойства соответствуют параметрам конструктора (с учётом разлиций в написании) не есть большая сложность для компилятора. А, субъективно конечно же, ценности работы компилятора это прибавит совершенно точно.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, VladD2, Вы писали:
_FR>>Я вот наоборот, просматривая исходники четвёртого фреймворка нарадоваться не мог тому, что количество sealed классов (даже с private областью вилимости) увеличилось и readonly поля стали использоваться заметно чаще. VD>Я тоже этому рад. Только вот в моем коде (а так же в коде Вольфхаунда и Хардкеса, которые так же работают над проектом), как раз трудно встретить изменяемые поля. И это правильно! VD>>>Сейчас ситуация постепенно выправляется, но все же императивная идеология крепко засела во многих головах (и в вашей, кстати, тоже).
А надо мной на последних работах коллеги стебались: что всё у меня sealed да internal/private, никак не расширить.не добавить полезного функциолнала
_FR>>Не понимаю почему вытравление императивной диалогии должно быть обязательно связано с гайдлайнами к именованию членов классов Этот аргумент в данном обсуждении по силе не хуже того, что у меня ухи торчком или нос пяточком. VD>Да не связано это с именованием. Это связано с отношением к полям. Есть изменяемые поля, а есть не изменяемые, и это две большие разницы! Неизменяемые поля на практике проблем не создают.
Да и изменяемые не создают, если их не изменять Я привык относиться к полям как к сущностям, хранящим информиацию, а к свойствам — как к сущностям, предоставляющим хранящуюся информацию. И очень не хочу разубеждаться в этом. Будет жаль, если этот поставит крест на моём желании работать более "функционально" с помощью Немерла. Придётся курить F# — синтаксис там конечно покучерявее, зато обсуждаемой проблемы нет. И в рекордах и в дискриминайтед юнионах честные, привычные, старые добрые свойства. Почему-то функциональное программирование на F# не заставляет меня по другому относиться к полям.
VD>Плюс именно иделогия влияет на твое восприятие объектов с публичными полями. Но это однобокая идеология! Есть и другие идеологии в которых открытая структура типов не является огромной проблемой. Варианты — это не совсем объекты. Они предлагают другую идеологию.
Варианты — это же дискриминайтед юнионы? Ну так где-то они сделаны по-другому.
VD>>>Меж тем никаких проблем с публичными полями нет, если, конечно, они доступны только на чтение. Более того, в таких условиях свойства просто не ясно зачем нужны. _FR>>Я же показал один пример — биндинг. Глубже думать пока нет необходимости. VD>А что биндинг? Биндинг твой — это как раз и есть проявление той самой императивной идеологии. Где-то это удобно. Но намного чаще рулят неизменяемые объекты. С ними логика становится проще.
И как неизменяемость объектов позволит проще отобразить список этих объектов в гриде?
VD>Что же до обсуждения, я уже все сказал. С кейсом — это такие же традиции, как и те гайдлайны о которых ты говоришь. VD>Сделать эксесоры конечно можно. Но поля сдеать приватными нельзя, так как это только для C#-а — это классы.
Весьма жаль. В таком виде дополнительные свойства конечно же лишь будут мешать.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, о парсере шарпа. Вот тут можно взять парсер на на основе АНТЛР-а. VD>Вот только для сборки нужна Ява и есть одна проблема. Для сравнения наш парсер в релизе работает примерно в 10 раз быстрее. И это при том что PegParser значительно гибче АНТЛР-а (например, рассчитан на динамическое расширение грамматики).
Здравствуйте, VladD2, Вы писали:
VD>С полями (о которых идет речь) конфликта не будет. Будет другое несоответствие гайдлайну. Поля станут кошерно-ПаскальКейсными, но такими же станут и параметры конструкторов.
Ну можно, наверное, сделать так, чтобы названия параметров конструкторов всегда переводились в кэмел, раз людей сей факт так беспокоит.
Здравствуйте, Воронков Василий, Вы писали:
VD>>С полями (о которых идет речь) конфликта не будет. Будет другое несоответствие гайдлайну. Поля станут кошерно-ПаскальКейсными, но такими же станут и параметры конструкторов.
ВВ>Ну можно, наверное, сделать так, чтобы названия параметров конструкторов всегда переводились в кэмел, раз людей сей факт так беспокоит.
Как верно указал Влад где-то выше, это будет ещё хуже.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
ВВ>>Ну можно, наверное, сделать так, чтобы названия параметров конструкторов всегда переводились в кэмел, раз людей сей факт так беспокоит. _FR>Как верно указал Влад где-то выше, это будет ещё хуже.
Здравствуйте, VladD2, Вы писали:
VD>Что же до обсуждения, я уже все сказал. С кейсом — это такие же традиции, как и те гайдлайны о которых ты говоришь. VD>Сделать эксесоры конечно можно. Но поля сдеать приватными нельзя, так как это только для C#-а — это классы.
Вот кстати написал на F# такой тип:
type XColor = { X : double; Y: double; Z: double; }
Конструктор, что для меня лично не удивительно, компилятор сгенерировал такой:
public XColor(double x, double y, double z);
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>Ну можно, наверное, сделать так, чтобы названия параметров конструкторов всегда переводились в кэмел, раз людей сей факт так беспокоит. _FR>>Как верно указал Влад где-то выше, это будет ещё хуже.
ВВ>Ссылочку не дашь? Я что-то не нахожу.
По этому если сделать имена полей с большой буквы, то с большой буквы будут и имена параметров конструкторов. Это еще хуже соотносится с гайдлайнами.
_FR>По этому если сделать имена полей с большой буквы, то с большой буквы будут и имена параметров конструкторов. Это еще хуже соотносится с гайдлайнами.
Я имел в виду можно сделать так, чтобы компилятор, генерируя названия полей для конструктора, автоматически приводил бы их в кэмел-регистр. Т.е. поля бы ты назвал в Паскале, названия параметров получились бы в Кэмеле — и все довольны.
_FR>>По этому если сделать имена полей с большой буквы, то с большой буквы будут и имена параметров конструкторов. Это еще хуже соотносится с гайдлайнами.
ВВ>Я имел в виду можно сделать так, чтобы компилятор, генерируя названия полей для конструктора, автоматически приводил бы их в кэмел-регистр. Т.е. поля бы ты назвал в Паскале, названия параметров получились бы в Кэмеле — и все довольны.
А, понял. Только вот фраза "названия полей для конструктора" неочём: у конструктора есть параметры.
Здравствуйте, VladD2, Вы писали:
VD>Парсер прогоняли на куче исходников. От Януса, до исходников дотнета. Вроде пашет.
Ты мог бы дать мне консольную утилитку, которой я скармливаю имя файла с исходником C#, а она его парсит и дампит дерево в какой-нибудь текстовой форме? Если найду баги, обещаю сообщить.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, adontz, Вы писали:
VD>Парсер прогоняли на куче исходников. От Януса, до исходников дотнета. Вроде пашет.
Что пашет? AST разбирается без выброса Exception. Или эти исходники без правки, целиком компильнулись (парсинг вместе с Немерлевской кодогениерацией) в работающее приложение ?
VD>По этому если сделать имена полей с большой буквы, то с большой буквы будут и имена параметров конструкторов. Это еще хуже соотносится с гайдлайнами.
А вроде ничего страшного на первый взгляд в этом не видно, если с большой буквы:
match (ast)
{
| Alias(Id) => WriteLine(Id);
... // другие образцы
}
Даже лучше заметно что это имя привязано к члену класса а не произовльно выбираемые имена как в | h::t ->
Хотя это все мелочи.
Это же все скорее примерный аналог доступа к полям, чем объявление локальной переменной.
Смесь VB с C#
if(obj is ...)
{
var ast=(Alias)obj;
With ast
WriteLine(.Id);
End With
}
Здравствуйте, adontz, Вы писали:
A> ...Максимум на что ты можешь сегодня расчитывать — это использование твоего парсера из C#. Причём удобное использование, чтобы Nemerle не торчал из библиотеки во все стороны.
К сожалению с парсером немного другая ситуация. Максимум на что мы можем расчитывать это подарок свыше (от MS), парсер C# и то через несколько лет, хорошо если 1-2, а может через 4 года. А тут любители сели за пару дней себе написали парсер C# на коленке. Практически полный.
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, VladD2, Вы писали:
VD>>Парсер прогоняли на куче исходников. От Януса, до исходников дотнета. Вроде пашет.
N>Ты мог бы дать мне консольную утилитку, которой я скармливаю имя файла с исходником C#, а она его парсит и дампит дерево в какой-нибудь текстовой форме? Если найду баги, обещаю сообщить.
Утиллитка подобная у нас есть, но дамп она не делает — она просто сообщает произошел ли разбор, и если он произошел, были ли (и в каких местах) синтаксические ошибки.
В принципе возможно сделать так, чтобы она дампила дерево.
Здравствуйте, hardcase, Вы писали:
N>>Ты мог бы дать мне консольную утилитку, которой я скармливаю имя файла с исходником C#, а она его парсит и дампит дерево в какой-нибудь текстовой форме? Если найду баги, обещаю сообщить.
H>Утиллитка подобная у нас есть, но дамп она не делает — она просто сообщает произошел ли разбор, и если он произошел, были ли (и в каких местах) синтаксические ошибки.
Если нам не помогут, то мы тоже никого не пощадим.
Почему нельзя сделать так же: пользователь указывает
Этот аргумент в данном обсуждении по силе не хуже того, что у меня ухи торчком или нос пяточком.
Я привык относиться к полям как к сущностям, хранящим информиацию, а к свойствам — как к сущностям, предоставляющим хранящуюся информацию. И очень не хочу разубеждаться в этом. Будет жаль, если этот поставит крест на моём желании работать более "функционально" с помощью Немерла. Придётся курить F# — синтаксис там конечно покучерявее, зато обсуждаемой проблемы нет. И в рекордах и в дискриминайтед юнионах честные, привычные, старые добрые свойства. Почему-то функциональное программирование на F# не заставляет меня по другому относиться к полям.
