Ячейка памяти.
nesco, посмотри на то, о чем говорили вчера

Ты че, тупо переименовал doClear в doDefault

Не только

Если оно делает то же, что doClear, то называть нужно было тогда уж doReset. doDefaul подразумевает по логике установку того, что будет потом возвращаться по doReset. doClear действительно не логично, но оно устоялось в нескольких компонентах. В HiAsm много чего названо не логично или ошибочно, но замена названий приведёт к потере совместимости, посему никто не рискует.

Tad, концепцию HiAsm пытаетесь нарушить? (Верхняя точка -- Свойство -- Поток) Иногда мешает событие на выходе при doClear, уж лучше свойство сделать Выдавать/Не выдавать

Все же, я не стал бы менять логику имен и сделал бы твои методы наоборот

именно дефолтное значение. doClear - подразумевает сброс в Null.
Если подключена кудато верхняя точку, то изменить данные в Memory по входу doValue связано с такими танцами с бубном, что мало не покажется.
Никакого нарушения концепции HiAsm, а вот принципы построения компонент - не против.
------------ Дoбавленo в 18.36:
Леонид, просто хочу объявить войну вот этой строке:
которая думает за меня.
Человек должен сам думать, что ему нужно в данный момент -
или значение из _prop_Text,
или из верхней _data_Text,
или со входа.
Сейчас, для достижения этого, приходится шаманить и строить костыли.
------------ Дoбавленo в 18.41:
с чем ? Я не предлагаю менять названия в старых компонентах, а только в новых давать названия, отвечающие полностью производимым действиям.

Tad, и что мешает-то? Где костыли?

Assasin,
1. сегодня на провокации не поддаюсь.
2. Ты ещё забыл, что есть ещё и _prop_Text

Tad,
1. А я и не провоцирую, я веду конструктивный разговор
2. Дак я показал пример того, как может пользователь сам выбирать, что и когда считывать и при каких условиях, а не заинлайнил ReadString в код

Assasin, откуда вырезка ?

Из моей головы Вот только про "заинлайнить ReadString" я переборщил, функциональность немного отличается.

Assasin, а я предложил самый простой и понятный даже начинающим метод - отдельные точки выбора данных.
Проще всего продемонстрировать предложение было на компоненте Memory. В нем пришлось добавить всего одну точку.
Где я не прав ?
Про совместимость говорить не надо. У нас её и так нет.
Про ускорение работы компонент (это и ежу понятно) и про повышение функциональности можно и поговорить.

Методы ToXXXX не поддерживают цепочные данные. Кроме того, я совершенно не вижу большой ценности данного предложения, как и переделывании концепции умирающего пакета.
Я не против в добавлении двух отдельных точек для чтения только потока и только верхней точки (doInputValue и doDataValue), но категорически против наслоения алгоритмов на уже готовые имена точек

Пакет делфи умирает? Не думаю что он в ближайшие 10 лет умрёт! Он ещё долго будет жить! ИМХО!