Здравствуйте, Abyx, Вы писали:
A>ок, пока я вижу только такое применение:
Я не понимаю, что ты пытаешься доказать?
То, что без этого можно обойтись?
Да можно.
Но и без обычных методов расширений можно обойтись.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, michael_isu, Вы писали:
_>Значит добавил "деревьев", за которыми не видно "леса". Т.е. добавил технических малозначительных методов, которые среди значимых методов DoSome и прочих как бельмо на глазу. Зачем загружать мозг читателя этого кода лишней информацией? (7+-2, ага) Ему скорее всего совершенно не интересен будет этот метод, а его наличием заставляешь загружать его в мозг волей-неволей, а мозги стоит беречь, не только того кто залезет в этот код, но и свои тоже.
1)Методы для того и разделяют чтобы убирать лишнюю информацию и беречь людям мозг.
2)Приватные методы для того и придумали чтобы убирать туда код который нужен только в данном классе.
3)Убирание метода в другой класс количество сущностей увеличивает. Появляется новый класс.
_>Предлагаю положить его в TestExtensions и использовать как экстеншн метод. Если в разных местах нужна разная логика хождения — делаешь 2 разных extensions-класса и подключаешь нужный через namespace по месту.
А то, что мне нужно обращаться к данным, которые лежат в экземпляре класса ты конечно не заметил.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>они будут доступны только внутри Test? WH>Да. C# кстати позволяет приватные методы расширения делать.
A>>непонятно тогда в чем профит по сравнению с AsBar(foo).SomeBarMethod(); WH>А в чем профит обычных методов расширений? WH>Ведь всегда можно использовать обычный синтаксис.
обычные методы расширения доступны "глобально", их можно сделать библиотекой и реюзать.
а если экземплярные можно юзать только внутри реализации классов, это не очень-то интересно.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, michael_isu, Вы писали:
_>>Захламил класс Test методом AsBar. Зачем? WH>Что значит захламил? Что ты предлагаешь? Напрямую в someTable ходить? А если логика чуть сложнее?
Значит добавил "деревьев", за которыми не видно "леса". Т.е. добавил технических малозначительных методов, которые среди значимых методов DoSome и прочих как бельмо на глазу. Зачем загружать мозг читателя этого кода лишней информацией? (7+-2, ага) Ему скорее всего совершенно не интересен будет этот метод, а его наличием заставляешь загружать его в мозг волей-неволей, а мозги стоит беречь, не только того кто залезет в этот код, но и свои тоже.
Предлагаю положить его в TestExtensions и использовать как экстеншн метод. Если в разных местах нужна разная логика хождения — делаешь 2 разных extensions-класса и подключаешь нужный через namespace по месту.
Здравствуйте, Abyx, Вы писали:
A>они будут доступны только внутри Test?
Да. C# кстати позволяет приватные методы расширения делать.
A>непонятно тогда в чем профит по сравнению с AsBar(foo).SomeBarMethod();
А в чем профит обычных методов расширений?
Ведь всегда можно использовать обычный синтаксис.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Какие будут мысли насчет данной функциональности?
Мне нравится. Часто их не хватает. То, что написать можно и по другому это фигня, когда хочется именно такого синтаксиса. Ограничивать private не стоит, как минимум нужен еще и protected, а то и public, пусть его снаружи вызывают обычным способом, а внутри как метод расширения.
Здравствуйте, Ziaw, Вы писали:
Z>Ограничивать private не стоит, как минимум нужен еще и protected, а то и public, пусть его снаружи вызывают обычным способом, а внутри как метод расширения.
А я этого и не предлагал.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>доказывать тут должен только ты. A>>motivating example и всё такое. WH>Так я в первом сообщении показал что хочу.
да, я понял что ты хочешь, но не понял зачем это надо.
вот представь, есть операция деления "a / b",
а ты пишешь, "хочу чтоб можно было писать `b \ a` вместо `a / b`".
всем понятно *что* ты хочешь, непонятно *зачем*.
Здравствуйте, WolfHound, Вы писали:
A>>доказывать тут должен только ты. A>>motivating example и всё такое. WH>Так я в первом сообщении показал что хочу.
Мотивация нигде не раскрыта, ты просто показал "что", а мотивация это "для чего".
class Test {
private _someTable : Map[Foo, Bar];
implicit def foo2Bar(foo: Foo): Bar = _someTable(foo)
private DoSome() {
foo.SomeBarMethod()
}
}
Очень мощная штука, только нужно быть с ней очень осторожным. В Scala 2.10 это фичу даже нужно включать специальным импортом (import language.implicitConversions)
В теории практика не отличается от теории, но на практике — отличается
Да вроде бы имеет право на жизнь. В Scala похожее можно делать:
import scala.collection.mutable.HashMap
import scala.language.implicitConversions
case class Test1(str: String)
class Test3(v: String) {
def getV(): String = { v };
}
class Test2 {
private val map = new HashMap[Test1, Test3]
implicit private def asBar(test1: Test1): Test3 = {
map.get(test1).get
}
private def doSome(test1: Test1): String = {
test1.getV()
}
}
Да, синтаксис другой. И методы через обертку обычно добавляются (keywords: pimp my library pattern). Хотя в 2.10 сделали инлайнинг оберток для случаев, поэтому обычные extension methods теперь будут без оверхеда.
Здравствуйте, michael_isu, Вы писали:
_>Захламил класс Test методом AsBar. Зачем?
Что значит захламил? Что ты предлагаешь? Напрямую в someTable ходить? А если логика чуть сложнее?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, nau, Вы писали:
nau>Правильно ли я понимаю, что тебе хочется Scala implicit conversions?
Что-то типа того. Только явное.
nau>Очень мощная штука, только нужно быть с ней очень осторожным. В Scala 2.10 это фичу даже нужно включать специальным импортом (import language.implicitConversions)
В немерле обычное дело синтаксис импортами подключать.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, michael_isu, Вы писали:
_>>Значит добавил "деревьев", за которыми не видно "леса". Т.е. добавил технических малозначительных методов, которые среди значимых методов DoSome и прочих как бельмо на глазу. Зачем загружать мозг читателя этого кода лишней информацией? (7+-2, ага) Ему скорее всего совершенно не интересен будет этот метод, а его наличием заставляешь загружать его в мозг волей-неволей, а мозги стоит беречь, не только того кто залезет в этот код, но и свои тоже. WH> WH>1)Методы для того и разделяют чтобы убирать лишнюю информацию и беречь людям мозг.
Когда методов становится слишком много (кол-во строк кода > 25.000), одним разделением методов не отделаетесь.
WH>3)Убирание метода в другой класс количество сущностей увеличивает. Появляется новый класс.
Ничего страшного.
_>>Предлагаю положить его в TestExtensions и использовать как экстеншн метод. Если в разных местах нужна разная логика хождения — делаешь 2 разных extensions-класса и подключаешь нужный через namespace по месту. WH>А то, что мне нужно обращаться к данным, которые лежат в экземпляре класса ты конечно не заметил.
Не заметил.
Вообще пихать в один класс диспетчеризацию и бизнес-логику — дурной тон. Конкретно — Test'у нужен только Bar, все остальное нужно оттуда выпилить. Если это сделать — вопрос и проблемы уйдут сами собой.
Здравствуйте, WolfHound, Вы писали:
WH>Какие будут мысли насчет данной функциональности?
Категорически против. Синтаксис foo.AsBar() в C# несет семантику: выполнить метод AsBar на основании состояния переменной foo (плюс глобальное статическое состояние). Статик экстеншионы не меняют эту семантику. Вы же хотите прилепить туда еще this.
Здравствуйте, Pro100Oleh, Вы писали:
PO>Здравствуйте, WolfHound, Вы писали:
WH>>Какие будут мысли насчет данной функциональности?
PO>Категорически против. Синтаксис foo.AsBar() в C# несет семантику: выполнить метод AsBar на основании состояния переменной foo (плюс глобальное статическое состояние). Статик экстеншионы не меняют эту семантику. Вы же хотите прилепить туда еще this.
Не вижу проблемы, что будет такое неявное замыкание на this. Для остальных методов же оно есть — нет необходимости всегда писать "this." для доступа к другим методам того же класса.
Здравствуйте, Pro100Oleh, Вы писали:
PO>Категорически против. Синтаксис foo.AsBar() в C# несет семантику: выполнить метод AsBar на основании состояния переменной foo (плюс глобальное статическое состояние). Статик экстеншионы не меняют эту семантику. Вы же хотите прилепить туда еще this.
Это ничем не отличается от замыкания. Которое вполне укладывается в семантику C#.
