Здравствуйте, GlebZ, Вы писали:
GZ>Нет. В честь чего?
Не знаю. Вот правило:
Семантика такая: конструктор — это метод, в который передаётся некоторое "начальное" состояние объекта
То, что это правило разрешает MyStringCollection(string[]), но запрещает MyStringCollection(TextReader), на мой взгляд неочевидно. К примеру вполне логично, что то самое "состояние объекта" было сохранено в файле и теперь читается из него при создании экземпляра MyStringCollection.
Здравствуйте, igna, Вы писали:
I>Если твое правило запрещает конструктор MyStringCollection(string[]), то я не понимаю, почему оно разрешает MyStringCollection(IEnumerable<string>), если же наоборот, то неясно, почему запрещен MyStringCollection(TextReader).
Повторюсь: с чего ты взял, что "оно разрешает MyStringCollection(IEnumerable<string>)"? Я уже говорил немного выше, что это — ключевой момент.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, igna, Вы писали:
I>Не знаю. Вот правило:
I>
I>Семантика такая: конструктор — это метод, в который передаётся некоторое "начальное" состояние объекта
I>То, что это правило разрешает MyStringCollection(string[]), но запрещает MyStringCollection(TextReader), на мой взгляд неочевидно. К примеру вполне логично, что то самое "состояние объекта" было сохранено в файле и теперь читается из него при создании экземпляра MyStringCollection.
Есть набор типов встроенных в среду и компилятор. Нам в голову ни придет что надо писать логику сложения для int или double. Она уже реализована компилятором. string[] или IEnumerable<T> — не сильно отличается от int. В отличие от TextReader, который требует отдельной логики доступа.
Здравствуйте, GlebZ, Вы писали:
GZ>Есть набор типов встроенных в среду и компилятор. Нам в голову ни придет что надо писать логику сложения для int или double. Она уже реализована компилятором. string[] или IEnumerable<T> — не сильно отличается от int. В отличие от TextReader, который требует отдельной логики доступа.
Логика у него есть и называется метод GetLine. То есть TextReader фактически имплементирует паттерн Iterator. Но дело даже не в этом, а в том, что аргументация твоя есть нечто дополнительное к правилу Фреда.
Я прошу тебя высказать твоё собственное мнение. Почему ты даёшь ссылку на пост другого человека?
Ответь пожалуйста на мой вопрос чётко и прямо. Если не можешь — значит или не хочешь или недостаточно подумал.
В любом из этих двух случаев продолжать бессмысленно.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Я прошу тебя высказать твоё собственное мнение. Почему ты даёшь ссылку на пост другого человека? _FR>Ответь пожалуйста на мой вопрос чётко и прямо. Если не можешь — значит или не хочешь или недостаточно подумал.
Хорошо, господин учитель.
IEnumerable<string> полностью описывает состояние объекта, поэтому конструктор MyStringCollection(IEnumerable<string>) разрешен правилом Фреда.
Здравствуйте, igna, Вы писали:
_FR>>Я прошу тебя высказать твоё собственное мнение. Почему ты даёшь ссылку на пост другого человека? _FR>>Ответь пожалуйста на мой вопрос чётко и прямо. Если не можешь — значит или не хочешь или недостаточно подумал.
I>Хорошо, господин учитель.
Давай всё-таки без подхолимажа и прочей гомосятины, ладно? Это называется переходом на личности.
I>IEnumerable<string> полностью описывает состояние объекта,
"состояние" какого "объекта"? Допустим:
IEnumerable<string> items = GetItems();
List<string> list = new List<string>(items);
так "состояние" какого "объекта" здесь "полностью" описывается с помощью "IEnumerable<string>"? Первого — возможно, но при чём здесь состояние этого объекта? Второго — не правда. Состояние List<string> не описывается полностью параметром конструктора, принимающего перечислииель.
I>поэтому конструктор MyStringCollection(IEnumerable<string>) разрешен правилом Фреда.
Покажи мне место в том, что ты называешь "правилом Фреда", где бы говорилось хоть что-нибудь о то, что "полностью описывает состояние объекта" Нигде я ничего подобного не говорил. Всё-таки ты всё ещё тролишь, ибо перевираешь слова собеседника и вместо чётких формулировок выдаёшь оскорбительные ("Хорошо, господин учитель. ") и расплывчатые. Посему вместо ответа на свои вопросы ты получаешь всё новые вопросы :о)) "Так держать".
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>"состояние" какого "объекта"?
Ну значит я неправ.
_FR>Покажи мне место в том, что ты называешь "правилом Фреда", где бы говорилось хоть что-нибудь о то, что "полностью описывает состояние объекта" Нигде я ничего подобного не говорил.
Значит я опять неправ.
Значит неверно понял правило. Честно говоря не знаю, что еще написать, чтобы ты не принял мои слова за стеб и ответил все же на вопрос, допускает ли твое правило MyStringCollection(string[]) или нет. Может это можно непублично как-нибудь выяснить? Я уже готов дать свой адрес, хоть и стращают всякие разные.
Здравствуйте, igna, Вы писали:
_FR>>"состояние" какого "объекта"?
I>Ну значит я неправ.
Почему и в чём?
_FR>>Покажи мне место в том, что ты называешь "правилом Фреда", где бы говорилось хоть что-нибудь о то, что "полностью описывает состояние объекта" Нигде я ничего подобного не говорил.
I>Значит я опять неправ. I>Значит неверно понял правило.
Отлично.
I>допускает ли твое правило MyStringCollection(string[]) или нет.
Допускает или нет — зависит не от типов параметров, а от того, как переданный массив используется. По одному объявлению ответить на вопрос невозможно.
Давай с классом List<> разберёмся (поскольку его реализация нам известна), вернее с его конструктором List<>(IEnumerable<>). Я бы не добавлял такой [открытый] конструктор в класс, а конструирование списка из IEnumerable<> возложил бы на статический метод. Потому что такой вот код:
void Test(MyBusinessEntitiesCollection<MyEntity> items) {
var list = new List<MyEntity>(items);
var collection = new Collection<MyEntity>(items);
}
мне не нравится — через конструктор не передаётся связь между аргументом и созданным объектом. В первом случае происходит копирование, а во-втором — создаётся обёртка-декоратор.
Вот так вот, имхо, было бы гораздо понятнее:
void Test(MyBusinessEntitiesCollection<MyEntity> items) {
var list1 = items.ToList(); // "To" - значит скопировалиvar list2 = List.Create(items);
var collection = new Collection<MyEntity>(items);
var collection2 = items.AsMyDecorator(); // "As" - обернули
}
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Давай с классом List<> разберёмся (поскольку его реализация нам известна), вернее с его конструктором List<>(IEnumerable<>). Я бы не добавлял такой [открытый] конструктор в класс, а конструирование списка из IEnumerable<> возложил бы на статический метод.
Вот. Но кое-кто из согласных с твоим правилом твоего мнения по поводу этого конкретного конструктора не разделяет:
Остается первый конструктор к которому ты не написал комментария, если он такой же, как и List<string>(IEnumerable<string>) то все в порядке.
Здравствуйте, igna, Вы писали:
_FR>>Давай с классом List<> разберёмся (поскольку его реализация нам известна), вернее с его конструктором List<>(IEnumerable<>). Я бы не добавлял такой [открытый] конструктор в класс, а конструирование списка из IEnumerable<> возложил бы на статический метод.
I>Вот. Но кое-кто из согласных с твоим правилом твоего мнения по поводу этого конкретного конструктора не разделяет:
… I>То есть правило нечеткое.
ИМХО, очень сомнительный вывод. Впрочем, даже в этом топике не в первый раз, так что тролль себе дальше.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, fmiracle, Вы писали:
F>Как можно при создании списка зарезервировать сразу кусок памяти нужного размера, не передавая этот самый размер в конструктор — мне лично не ясно совершенно.
Здравствуйте, _FRED_, Вы писали:
_FR>ИМХО, очень сомнительный вывод. Впрочем, даже в этом топике не в первый раз, так что тролль себе дальше.
А зачем? Пока была вероятность, что правило Фреда имеет смысл, я пытался разобраться. А теперь все ясно. Но спасибо за разъяснения, другие просто убежали, почувствовав понятно что.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, igna, Вы писали:
I>>допускает ли твое правило MyStringCollection(string[]) или нет.
_FR>Допускает или нет — зависит не от типов параметров, а от того, как переданный массив используется. По одному объявлению ответить на вопрос невозможно.
Я полагаю, что параметром передается массив имен файлов.
_FR>Давай с классом List<> разберёмся (поскольку его реализация нам известна), вернее с его конструктором List<>(IEnumerable<>). Я бы не добавлял такой [открытый] конструктор в класс, а конструирование списка из IEnumerable<> возложил бы на статический метод. Потому что такой вот код: _FR>
_FR>void Test(MyBusinessEntitiesCollection<MyEntity> items) {
_FR> var list = new List<MyEntity>(items);
_FR> var collection = new Collection<MyEntity>(items);
_FR>}
_FR>
_FR>мне не нравится — через конструктор не передаётся связь между аргументом и созданным объектом. В первом случае происходит копирование, а во-втором — создаётся обёртка-декоратор.
_FR>Вот так вот, имхо, было бы гораздо понятнее: _FR>
_FR>void Test(MyBusinessEntitiesCollection<MyEntity> items) {
_FR> var list1 = items.ToList(); // "To" - значит скопировали
_FR> var list2 = List.Create(items);
_FR> var collection = new Collection<MyEntity>(items);
_FR> var collection2 = items.AsMyDecorator(); // "As" - обернули
_FR>}
_FR>
Согласен, что так понятнее. Но исторически конструктор List<T>(IEnumerablt<T>) появился раньше метода ToList(). Кроме этого я подозреваю что сей конструктор мог предназначаться для наследников от List<T>. Я знаю, что List<T> не предназначался для наследования, но и sealed он не помечен. Да и AFAIR в msdn попадались примеры с наследованием от него.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>Да и AFAIR в msdn попадались примеры с наследованием от него.
I>Это было бы интересно посмотреть. Вдруг кто знает, где.
На счет msdn не уверен, но в рефлекторе примеры найти не сложно.
Здравствуйте, samius, Вы писали:
I>>>допускает ли твое правило MyStringCollection(string[]) или нет. _FR>>Допускает или нет — зависит не от типов параметров, а от того, как переданный массив используется. По одному объявлению ответить на вопрос невозможно. S>Я полагаю, что параметром передается массив имен файлов.
Несомненно. Но тема кодировки не раскрыта
S>Согласен, что так понятнее. Но исторически конструктор List<T>(IEnumerablt<T>) появился раньше метода ToList(). Кроме этого я подозреваю что сей конструктор мог предназначаться для наследников от List<T>. Я знаю, что List<T> не предназначался для наследования, но и sealed он не помечен. Да и AFAIR в msdn попадались примеры с наследованием от него.
Нет, наследование здесь не при чём. Дело просто в том, что этот конструктор не делает ничего такого, что нельзя было бы сделать без него (а конструктор с capacity делает). А в [открытый] интерфейс типа без крайней необходимости вообще лучше не добавлять ничего, чего нельзя было бы сделать без имеющегося [открытого] интерфейса.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Нет, наследование здесь не при чём. Дело просто в том, что этот конструктор не делает ничего такого, что нельзя было бы сделать без него (а конструктор с capacity делает).
То, что "конструктор с capacity делает чего такого", не обязывает его быть открытым.
Здравствуйте, igna, Вы писали:
F>>Как можно при создании списка зарезервировать сразу кусок памяти нужного размера, не передавая этот самый размер в конструктор — мне лично не ясно совершенно. I>Это верно, но конструктор-то может быть закрытым.
Не понятно к чему это.
Конструктор с указываемой Capacity интересен именно как открытый.
Я уже говорил немного выше, что это — ключевой момент.
Это называется переходом на личности.
