Всем привет!

Мы планируем выложить новую версию компонента SynUniHighlighter 2.0 на этой неделе.
Если у нас не получится закончить в срок, то следующий релиз будет только аж в сентябре
Нужна ваша помощь в некоторых идеологических моментах...

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

1). Обобщённое название для открывающего и закрывающего "тегов" диапазона. Понятие "тег" включает в себя совокупность как строковых значений, так и значения некоторых свойств (таких как PartOfTerm - "часть слова", StartLine - "начинается с начала строки" и т.п.). Пока что соответствующий ему класс зовётся TSynSymbol и TSynMultiSymbol (из-за добавления мультитеговости). В файл раньше писался по отдельности, теперь же вынесен в отдельные теги OpenTag и CloseTag.
Но название "тег" для этого понятия немного не подходит, так как под "тегом" понимается нечто другое. "Symbol" или "Keyword" уже немного ближе, но тоже не очень стыкуется со смысловой нагрузкой. А "Word" - имхо, совсем не подходит...
Есть еще какие-нибудь идеи?

2). Обобщённое понятие пары откр. и закр. тегов. Нужно придумать хорошее словечко для них. Если не получится, то можно попробовать множественное число от пункта 1)., но это мне видится плохим решением...
Может что-то вроде "CoupleTags"... Но как-то по короче... И по правильней...

3). Обобщённое понятие мультитеговости, то есть множественности строковых значений для тегов (подробнее читайте здесь). Раньше звалось "MultiTags", возможно подойдёт просто как приставка Multi ко второму или первому пункту.

4). Название для откр. и закр. символов задающих CodeFolding.

5). Если нужно поменять название других составляющих подсветки, то пишите скорее сюда, так как после выхода версии 2.0 не хотелось бы снова серьёзно дорабатывать формат файла и менять название элементов дизайнера...

1. "Token" или лучше "RangeToken"
2. TwinRangeTokens
3. MultiRangeTokens или RangeMultiTokens
4. FoldingTokens, OpenFoldingToken, CloseFoldingToken
5. Вроде нет.

Годится?

...

Это сообщение отредактировал(а) Quadr0 - 15.7.2011, 00:57

Цитата(StayAtHome @ 3.8.2005, 19:58)

Годится?

Да! Очень симпатишная идея!
ИМХО, это самое оно. "Token", "PairTokens", "MultiTokens".
Если не найдём варианта еще лучше, то, наверное, будем юзать именно этот!

Может быть заодно решить проблему с KeyList (Keywords)? Обзовём его TokenList?
Ведь в нём на самом деле не только ключевые слова хранятся. В нём и список символов присутствует. А в скором времени и список регулярных выражений будет... Так что название KeyList, имхо, для него уже очень не подходит... устарело...

Цитата(Quadr0 @ 4.8.2005, 00:25)

Vitalik, а чем теущие неустраивают? И, кстати, менять их мы вроде не можем, они же ведь к SynEdit привязаны будут. Или я что-то не так понял?

Да, ты что-то не так понял.
Мы думаем над форматом файла и над интерфейсом дизайнера. То есть какие слова использовать в файле и естественно стараться такие же на форме дизайнера
Отностиельно нашего компонента, таким же образом потом можно и классы назвать.
Правда для выбора слов для CodeFolding нам, наверное, придётся быть более консервативными и не уходить далеко от названий классов/свойств в реализации этого самого CodeFolding'а

1. bracket, paranthesis;
LeftBracket, RightBracket

Цитата

2. TwinRangeTokens

а как вам TokenPair? или BracketPair?

Цитата(Sagara @ 4.8.2005, 11:26)

bracket, paranthesis

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

Но спасибо за вариант!

Скобки бывают круглые, квадратный, угловые... Bracket может быть использовано в абстрактном смысле. ну или в функциональном -- они определяют границы некотой "фразы" (в расширенном смысле этого слова).
Нужно название для класса объектов -- что-нть вроде AbstractBracket... но Bracket короче... и опять же сами по себе скобки и так бывают разные.

...

Это сообщение отредактировал(а) Quadr0 - 15.7.2011, 00:59

Цитата(Quadr0 @ 4.8.2005, 12:15)

Тогда, я думаю, эти названия нужно как-то с названиями диапазона синхронизировать.

Синхронизировать было бы, конечно, не плохо... Но всё же с CodeFolding там немножко по-другому...

Цитата(Quadr0 @ 4.8.2005, 12:15)

Т.е. FoldingTokens подойдут.

Ну... Там только пара отдельных "токенов", поэтому может тогда те теги в файле обозвать OpenToken и CloseToken? Обсуждение здесь.


Это сообщение отредактировал(а) Vitalik - 4.8.2005, 17:07

Итак, идея с "Tokens" мне очень понравилась! Она очень универсальна и очень хорошо отражает суть вещей!
Предлагаю следующим образом изменить названия внутренних классов для большей понятности и наглядности исходников.

• Был раньше такой универсальный класс TSynSymbol. Он использовался и как откр./закр. теги для диапазона, а также в списке токенов и в дереве токенов. Но с появлением многотеговости это уже можно разбить на три отдельных связанных наследственностью класса:
  • Класс родитель. Содержит свойства токена. Используется в дереве токенов.
    Варианты названия: TTokenProps, TTokenProperites, TAbstractSynSymbol, TCustomSynToken, ... ваш вариант?..
  • Наследник первого класса с добавлением свойства-строки. Используется в списке токенов. Это и был раньше TSynSymbol.
    Новое название: TSynToken
  • Тоже наследник первого класса, но добавляет список строк (мультитеговость). Это класс используется в качестве откр./закр. символов диапазона.
    Новое название: TSynMultiToken
• Класс для правила KeyList (Keywords). Старое название: TSynKeyList.
  Новое название: TSynTokenList (причины читайте выше)
• Класс TSymbolNode - узел дерева токенов.
  Новое название: TTokenNode или как-то так...
• Класс TSymbolList - список узлов в дереве токенов
  Новое название: TTokenNodeList

Это сообщение отредактировал(а) Vitalik - 4.8.2005, 20:17

На самом деле эти вещи, на мой взгляд, лучше назвать лексемой (lexeme). В принципе, token тоже переводится как лексема, но во-первых, у token есть у другое понятие (маркер, метка), во-вторых, термин token уже используется в highlighter'e именно для того, для чего он более подходит - выделенная последовальность рассматриваемая парсером. То есть token - это то, что мы можем рассмотреть как лексическую единицу, а лексема - это конкретная лексическая еденица имеющая смысл. Мне так кажется понятнее и менее запутывающе.

Соотвественно мои варианты были бы:
1. Lexeme. TLexeme (или THglLexeme). - Лексема. Лексема подсветки.
2. Lexeme pair. RangeLexemePair - Лексемная пара диапазона.
3. MultiLexeme - Множественная лексема.

A может так:

1. SignRange
2. DoubleSigns
3. MultiSigns
4. OpenFolding, CloseFolding (OpenFold, CloseFold)
5. Нет

Добавлю и я свою ложку дегтя

А чем вам слово тэг не нравиться? Тем что не нравиться? Или тем что на HTML-ое слово похоже?

Имхо - то что доктор прописал.

Цитата(jasny @ 5.8.2005, 08:43)

А чем вам слово тэг не нравиться? Тем что не нравиться? Или тем что на HTML-ое слово похоже?

Мне в принципе оно до сего момента очень нравилось, да и привык я к нему.
Но Quadr0 высказал мысль о том, что тега - это <...> и не подходит для нашего случая...
Поэтому я и создал эту темку.
А StayAtHome предложил интересную мысль о "токенах". Она мне понравилась тем, что немного лучше отражает суть вещей в парсинге подсветки. Так как что ключевое слово, что откр./закр. символы диапазона - это в конечном счёте суть просто "токены".

Цитата(ActioN @ 4.8.2005, 23:06)

1. SignRange 2. DoubleSigns 3. MultiSigns

Sign - это больше "знак", "символ", "буква"... Так что немножко не подходит по смыслу.
Во-первых, у нас не одиночный "символ", а, во-вторых, у этих классов должно быть что-нибудь общее от "лексемы", "тега" или чего-то в этом роде...
Но спасибо за мнение!

Цитата(Fantasist @ 4.8.2005, 22:52)

На самом деле эти вещи, на мой взгляд, лучше назвать лексемой (lexeme). Соотвественно мои варианты были бы: 1. Lexeme. TLexeme (или THglLexeme). - Лексема. Лексема подсветки. 2. Lexeme pair. RangeLexemePair - Лексемная пара диапазона. 3. MultiLexeme - Множественная лексема.

Хм... Лексема... Неплохая идея!..
Но пара моментов:
1). см. ниже (через две) мотивацию выбора token...
2). Небольшой минусик (личного характера): Lexeme - это три слога, а Token - два...

Цитата(Fantasist @ 4.8.2005, 22:41)

В принципе, token тоже переводится как лексема

Даже так: "лексема" переводится как "lexeme" только в лингвистическом и научном словарях, но как "token" в компьютерном и политехническом!

Цитата(Fantasist @ 4.8.2005, 22:41)

но во-первых, у token есть у другое понятие (маркер, метка)

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

Цитата(Fantasist @ 4.8.2005, 22:41)

во-вторых, термин token уже используется в highlighter'e именно для того, для чего он более подходит - выделенная последовальность рассматриваемая парсером.

Да, термин токен используется при выдаче SynEdit'у участков подсвеченного текста с помощью функций: GetToken, GetTokenAttribute, GetTokenKind, GetTokenPos...
Но также верно, что в списке токенов и дереве токенов используются именно эти классы "токенов", а мы просто отдаём SynEdit'у информацию об этих токенах... То есть в парсере мы работаем с "токенами" и отдаём информацию о токенах...
По-моему довольно логично и красиво

Цитата(Fantasist @ 4.8.2005, 22:41)

То есть token - это то, что мы можем рассмотреть как лексическую единицу, а лексема - это конкретная лексическая еденица имеющая смысл.

В приницпе что-то в этом есть... Но:

Цитата(Fantasist @ 4.8.2005, 22:41)

Мне так кажется понятнее и менее запутывающе.

Но это смотря как посмотреть... Так получается у нас вводится как будто бы еще одно новое понятие Lexeme, хотя на деле Token и Lexeme мало бы чем отличались...

Fantasist, удалось мне тебя убедить или мои доводы всё же слишком слабы?..

P.S. Что там по поводу ActiveX, сможешь заняться? Темка здесь

...

Это сообщение отредактировал(а) Quadr0 - 15.7.2011, 01:00

Цитата(Vitalik @ 5.8.2005, 08:03)

Даже так: "лексема" переводится как "lexeme" только в лингвистическом и научном словарях, но как "token" в компьютерном и политехническом!

Ну по-видимому, разные словори бывают, потому как перевод лексемы как lexeme я видел в "Словарь по вычислительной технике и программированию" и "Научно-технический словарь". Так что...

Цитата(Vitalik @ 5.8.2005, 08:03)

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

Ну, тут я имел в виду, что именно разные понятия, а не только значения. То есть например в сетевой топологии "ring" используется токен для обозначаения текущего места нахождения пакетов. И в Highlighter'e, как я уже говорил, используется как другое понятие.

Цитата(Vitalik @ 5.8.2005, 08:03)

Но также верно, что в списке токенов и дереве токенов используются именно эти классы "токенов", а мы просто отдаём SynEdit'у информацию об этих токенах... То есть в парсере мы работаем с "токенами" и отдаём информацию о токенах...

Это да, но если говорить о парсерах, то граммотно говоря, для текущего набора правил определен язык. Этот язык имеет некоторые слова(последовательность допустимых символов) которые имеют смысл. Это и есть лексемы. То есть, если парсер встречает что-нибудь типа "sdfssdfserw" - это будет для него токеном, но для языка определяющего правила подсветки это слова смысла не имеет (думаю вряд ли в каком-то языке такое слово будет определенно), следовательно не является лексемой. С другой стороны, конечно, для highlighter'а все слова не являются ошибочными, потому как для каждого из них есть информация о подсветке (по умолчанию).

Цитата(Vitalik @ 5.8.2005, 08:03)

Так получается у нас вводится как будто бы еще одно новое понятие Lexeme, хотя на деле Token и Lexeme мало бы чем отличались...

Не думаю, что мало. Как уже выше сказал - лексема - это слово определенное в языке (правилах) подсветки, тогда как токен - это любое слово рассматриваемое парсером (то есть как бы к правилам отношения вообще не имеет).

С другой стороны, я согласен, что для открывающих и закрывающих слов токен хорошо подходит - как раз "маркер открывающий/закрывающий range". Согласен и вот с этим:

Цитата(Vitalik @ 5.8.2005, 08:03)

Небольшой минусик (личного характера): Lexeme - это три слога, а Token - два...

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

Так что я спорить не буду - если действительно больше нравится токен, так его и надо оставлять. Мне, он тоже больше нравится, хоть я и думаю, что это менее логичнее. Но человек не является совершенно логическим существом.

Цитата(Fantasist @ 5.8.2005, 17:18)

лексема - это слово определенное в языке (правилах) подсветки, тогда как токен - это любое слово рассматриваемое парсером (то есть как бы к правилам отношения вообще не имеет)

А... Вон оно что... Теперь я понял, что ты имел ввиду!
Теперь я понимаю, что в твоих словах действительно было больше логики

Цитата(Fantasist @ 5.8.2005, 17:18)

Если понятие приятнее звучит, то и все остальные аргументы в пользу него найдутся...

Та да! Это ты верно подметил

Цитата(Fantasist @ 5.8.2005, 17:18)

...если действительно больше нравится токен, так его и надо оставлять.  Мне, он тоже больше нравится...

Значит, на том и порешили


P.S. Спасибо за столь подробное изложение своей мысли!

Цитата(Quadr0 @ 5.8.2005, 11:30)

Цитата(Vitalik @ 5.8.2005, 11:03) P.S. Что там по поводу ActiveX, сможешь заняться? Темка здесь А зачем? На базе старой версии делать? Уж лучше выхода текущей дождаться.

Ответил здесь. Давайте там обсудим этот ActiveX

гы....

впрочем, как всегда мое мнение по фигу.

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

понятно что если где-то что-то чего-то означает, то это не есть основание для перенятия названия.


я считал и считаю, что слово тэг - очень удачное название и означает они именно то, что надо (управляющая последовательность символов)

ну да по большому счету хозяин барин, понравилось - вперед и с песней

jasny, token просто действительно очень стыкуется с внутренней реализацией компонента...

[1] А теперь вот возник вопрос как бы лучше у этого Token'а и MultiToken'а обозвать свойства содержащие собственно строковое(ые) значение этих токенов?..
Сейчас это называется Symbol, что больше походит на "символ"...
Есть другие варианты?..

[2] Нужно каким-то одним образом обозвать символы-разделители (Delimiters, TermSymbols) и везде придерживаться такого названия.
Символы-разделители используются для:
• Определение на какие символы закрывается диапазон, если выбрано его свойство CloseOnTerm
• Если свойство диапазона PartOfTerm = False, то определяет символы, рядом с которыми может распологаться токен. С остальными символами (не разделителями) он стоять рядом не может.
• Функция GetIdentChars: TSynIdentChars возвращает в качестве символов идентификаторов все символы, кроме наших разделителей.
Итак, какое слово более красивое и более отражает вкладываемый в него смысл?..

Это сообщение отредактировал(а) Vitalik - 9.8.2005, 23:04

[1] Честно, не понял, о чем речь.

[2] Вообще, термин Term я выбрал как сокращение от terminal symbol - терминальный символ. То есть символ, который заканчивает слово (терминирует последовательность нетерминальных символов). Но тут я пока не могу с уверенностью сказать о правильности такого употребления.

Цитата(Fantasist @ 10.8.2005, 17:55)

[1] Честно, не понял, о чем речь.

Токен - это текст (строка, соответствующая токену) плюс свойства и атрибуты. Так вот это строковое свойство и нужно обозвать

Цитата(Fantasist @ 10.8.2005, 17:55)

[2] Вообще, термин Term я выбрал как сокращение от terminal symbol - терминальный символ.

Угу, я так и понял

Цитата(Fantasist @ 10.8.2005, 17:55)

Но тут я пока не могу с уверенностью сказать о правильности такого употребления.

Та да... Я тоже. Может delimiters тогда более подходит? Ведь теперь эти разделители разделяют не только в конце слова, но и в начале
Кстати, в файл TermSymbols писались как Delimiters