Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.22.61.187] |
|
Страницы: (16) « Первая ... 9 10 [11] 12 13 ... 15 16 все ( Перейти к последнему сообщению ) |
Сообщ.
#151
,
|
|
|
Киля, это твое решение будет работать далеко не для любых param1 и param2. Почитай что-ли ссылки, которые я дал выше.
Цитата Wound @ Далее есть ArgumentList - который представляет из себя массив строк. Можешь прям в него запихать аргументы командной строки. Цитата Запрашиваемая страница недоступна для .NET Framework 4.8. Вы перенаправлены на последнюю версию продукта, для которой доступна эта страница. |
Сообщ.
#152
,
|
|
|
Цитата applegame @ Запрашиваемая страница недоступна для .NET Framework 4.8. Вы перенаправлены на последнюю версию продукта, для которой доступна эта страница. https://docs.microsoft.com/ru-ru/dotnet/api...fo_ArgumentList Цитата Возвращает коллекцию аргументов командной строки, используемых при запуске приложения. C# public System.Collections.ObjectModel.Collection<string> ArgumentList { get; } Значение свойства Collection<String> Коллекция аргументов командной строки. Примеры В этом примере в сведения о запуске процесса добавляются два аргумента. C# var info = new System.Diagnostics.ProcessStartInfo("names.exe"); info.ArgumentList.Add("-first Mary"); info.ArgumentList.Add("-last Smith"); Комментарии ArgumentList, который поддерживается начиная с .NET Core 2,1 и .NET Standard 2,1, а Arguments свойство не зависит друг от друга. Это значит, что строки, назначенные ArgumentList коллекции, не используются для заполнения Arguments свойства, а строка, присвоенная Arguments свойству, не анализируется на отдельные строки, назначенные ArgumentList коллекции. ArgumentListпроще в использовании, Arguments чем свойство. Так как каждая строка назначается элементу коллекции, можно выполнить одиночную, а не тройную escape-последовательность строк, разделенных кавычками. Например, следующий пример включает -full "Mary Smith" в себя как член ArgumentList коллекции: C# info.ArgumentList.Add("-full \"Mary Smith\""; Arguments Свойство имеет соответствующее назначение: C# info.Arguments = "-full \"\"\"Mary Smith\"\"\"" При использовании этого свойства для задания аргументов Arguments командной строки необходимо установить пустую строку. Применяется к .NET Core 3.0 Preview 8 2.2 2.1 Добавлено Цитата applegame @ Киля, это твое решение будет работать далеко не для любых param1 и param2. Почитай что-ли ссылки, которые я дал выше. Ну ты ведь должен понимать что ты вообще ожидаешь? Это все что ты говоришь - синтетическая выдумка. Ну живет же как то народ. Я тебе выше написал разные вариации на тему, как можно. |
Сообщ.
#153
,
|
|
|
M Ввиду незрелости топик-стартера в плане идеологии Раста на момент создания топика - предлагаю переместить священные войны по топику в тему "Rust vs Чистейший Си" |
Сообщ.
#154
,
|
|
|
А что, тема себя изжила, что ли, и никому больше нечего тут сказать? JoeUser, ты может быть что-то для себя и решил ...невероятный случай для холивара... но тема куда ширее.
Добавлено Цитата applegame @ Суть: Цитата applegame @ Ну вот есть у тебя список аргументов в виде массива строк, и надо вызвать стороннюю программу с этими аргументами. В аргументах есть пробелы и слеши/бэкслеши, В шарпе параметры передаются в запускаемый процесс только в виде строки, причем она должна быть уже экранирована. Человеку не понравилось, что надо руками городить это самое экранирование, которое, как оказывается, не такое уж и тривиальное. Задача нерешаема без указания особенностей целевого приложения. Я вот не уверен, что кавычек для экранирования ему хватит. |
Сообщ.
#155
,
|
|
|
! Qraizer, признаю свою ошибку и тему открываю! Кому интересна тема раста и плюсов - вэлком сюда! Тема без ООП есть рядом. Простите, погорячился! |
Сообщ.
#156
,
|
|
|
Цитата Qraizer @ Только кавычек однозначно не хватит, поэтому и пишут сложные регекспы. И почему это задача нерешаема, если ее давно уже решили. Задача нерешаема без указания особенностей целевого приложения. Я вот не уверен, что кавычек для экранирования ему хватит. |
Сообщ.
#157
,
|
|
|
Цитата D_KEY @ Подожди. Вот есть у тебя в классе A метод foo. С какой-то реализацией. Наследники переопределили. Override не написали. Потом ты рефакторишь A и меняешь сигнатуру метода. Во всех наследниках код будет валиден и компилятору не к чему придраться, хотя это ошибка. Где-то ты поправил сам(потому что помнил), где-то свалились тесты. А где-то это уехало на прод Не? Если у тебя после этого все тесты остались зелёными, то либо никакой ошибки и вправду нет, и всё работает корректно, либо у тебя дерьмовые тесты и более серъёзные проблемы. =) Чуть позже распишу про «фатальный недостаток», далеко не уходи. =) Вкратце, он в использовании одной сущности для разных вещей (правильно, ведь зачем плодить сущности, если всё можно сделать одной мегауниверсальной сущностью, да?) |
Сообщ.
#158
,
|
|
|
Цитата korvin @ Если у тебя после этого все тесты остались зелёными, то либо никакой ошибки и вправду нет, и всё работает корректно, либо у тебя дерьмовые тесты и более серъёзные проблемы. =) Ну почему? Они же, вероятно, как раз дергают методы класса, который тестируют, а не базового класса, и это нормально. И такие тесты будут продолжать проходить. |
Сообщ.
#159
,
|
|
|
Цитата applegame @ Сиречь придумали универсальный протокол, придерживаться которого должны обе стороны.Ага? И почему это задача нерешаема, если ее давно уже решили. |
Сообщ.
#160
,
|
|
|
Вот смотри, рассмотрим сначала на примере интерфейсов и Java. Здесь и далее одиночное слово «интерфейс» подразумевает собственно сущность «интерфейс», объявляемую ключевым словом interface, а словосочетание «интерфейс класса» — набор всех публичных методов класса. protected и package-private не будем рассматривать для простоты. private методы во всей этой вакханалии не участвуют по определению. =) Методы, унаследованные от java.lang.Object тоже опустим, предположим, что любой объявляемый без указания родителя класс не имеет никаких унаследованных публичных методов. Как в C++, в общем. Интерфейсы могут использоваться для двух конкретных целей: 1. Поиметь несколько реализаций одного интерфейса под разные случаи жизни Классы в этом случае – реализуют только этот один публичный интерфейс – не имеют публичных методов сверх того – да и сами не публичны Пример: java.util.Iterator, его имплементации обычно – не реализуют никаких других публичных интерфейсов – не имеют других публичных методов – являются приватными классами коллекций, для которых реализуют итерацию 2. «Сузить» интерфейс класса для частных случаев Например, некий класс MutableQueue может реализовывать интерфейсы ReadableQueue и WritableQueue и использоваться в том или ином качестве по ситуации: одним клиентам будет отдаваться интерфейс только для чтения, другим — только для записи, а где-то будет использоваться и сам класс MutableQueue. Либо клиентам может отдаваться ещё более узкий интерфейс, например Iterable вместо конкретного ArrayList, используемого в качестве приватного поля объекта-контейнера. Так вот, в первом варианте, при строгом соответствии класса единственному интерфейсу такой автоматический рефакторинг сигнатур всех имплементаций оправдан и хорош. По крайней мере, если интерфейс не является частью SDK или какой-нибудь широкоиспользуемой библиотекой, и такое изменение не приведёт к необходимости изменения кучи стороннего кода самых разных людей, потере клиентов, банкротству твоего бизнеса и прочим катаклизмам. Да, придётся починить все имплементации, но само изменение будет семантически корректным. К слову, мы как-то обсуждали тесты для интерфейсов, вот это как раз тот случай, когда неплохо б иметь некоторый контракт для интерфейса в виде юнит-теста и автоматически запускать для всех реализаций, чтобы убедиться, что они ему следуют. Во втором же варианте, фактическим интерфейсом будет неявный собственный интерфейс класса, а дополнительные, «сужающие» интерфейсы — это просто некоторые аспекты (не имеет отношения к АОП), адаптации использования этого класса, фактически они выбирают из класс(а|ов) методы, а не класс реализует их методы, хоть это так выглядит, а значит нельзя просто взять и автоматически менять методы наследников при рефакторинге. Естественно на практике часто бывают не только два этих крайних варианта, но и разного рода смеси. To be continued… Добавлено Цитата D_KEY @ Они же, вероятно, как раз дергают методы класса, который тестируют, а не базового класса, и это нормально. И такие тесты будут продолжать проходить. Значит и использование классов продолжить быть корректной. В чём проблема? |
Сообщ.
#161
,
|
|
|
Цитата korvin @ Значит и использование классов будет продолжать быть корректным. При использовании через базовый класс/интерфейс не будет Портянки твои завтра уже прочитаю скорее всего |
Сообщ.
#162
,
|
|
|
Цитата D_KEY @ При использовании через базовый класс/интерфейс не будет Ты не включил в тесты производного класса тестирование методов из базового? Плохой тест. Тест должен тестировать класс целиком, а не только новые (по сравнению с базовым классом) методы. Плохие тесты. |
Сообщ.
#163
,
|
|
|
Цитата korvin @ Ты не включил в тесты производного класса тестирование методов из базового? Включил. И они проходят, потому что теперь тестируют методы нового класса. |
Сообщ.
#164
,
|
|
|
Цитата korvin @ …Продолжение последовало Теперь выделим оба варианта в отдельные сущности следующим образом: – для первого варианта будем использовать interface, дополнив её опциональным контрактом – для второго введём новую сущность и назовём её, например, protocol – для поддержки первого варианта классы теперь не могут быть использованы в качестве типа переменной, только интерфейсы и протоколы – класс не может быть просто унаследован от другого класса без описания расширенного интерфейса Для примера возьмём Iterable, Iterator, Set, HashSet и TreeSet из java.util. Рассмотрим только небольшое подмножество реализованных в JDK методов. Так же опустим некоторые детали реализаций, типа требования имплементации Comaparable для элементов TreeSet. Set у нас будет interface, Iterable — protocol, HashSet и TreeSet — классами, реализующими Set и удовлетворяющими Iterable. Т.е. в псевдо-Java: package jdk.collections import jdk.iter.Iterator // Note: not Iterable but Iterator public interface Set<A> { int size() boolean add(A a) boolean remove(A a) Iterator<A> iterator() // Note that Set is not extending/implementing/whatever-relating-to Iterable so no "override" needed } contract { void should_not_contain_duplicates() { ... } } package jdk.collections class HashSet<A> implements Set<A> { // fields and constructors // no need for "override" or specifying "public" // because all not-private methods are implementations of Set interface only int size() { ... } boolean add(A a) { ... } boolean remove(A a) { ... } Iterator<A> iterator() { ... } // private helping methods if needed // private methods are not comming from Set and do not override any Set method by design // so no need for "override" // Same thing: java.iter.Iterator is an interface private class Iterator<A> implements java.iter.Iterator<A> { // some implementation } } И то же самое для TreeSet, только с другой внутренней реализацией, само собой. Далее мы имеем protocol Iterable, определённый где-то в дргуом месте: package jdk.iter protocol Iterable<A> { Iterator<A> iterator() } и далее используем это всё вместе: package my.coolapp import jdk.collections.* import jdk.iter.* public void main(String[] args) { HashSet<String> words = new HashSet<>() // -- compilation error: class cannot be used as a type Set<String> words = new HashSet<>() // -- ok var words = new HashSet<String>() // -- ok, the type of words is Set<String> Iterable<String> words = new HashSet<>() // -- ok since Set has a method `Iterator<A> iterator()` which is required by Iterable } Зачем это всё? Чтобы лучше всё структурировать вместо каши из override и non-override методов, чтобы IDE лучше понимала семантику кода, в частности выполняла семантически более точный рефакторинг при изменении сигнатуры методов «родителей», который мы тут обсуждали. + один набор юнит-тестов на разные реализации. И при этом добавить некоторую гибкость в виде протоколов. Хз как там в ваших D/Rust/C#, но без аналога Go'шных интерфейсов или OCaml'овских object type'ов в Java грустновато. Но это только интерфейсы, осталось разобрать наследование реализаций (классов)… Добавлено Цитата D_KEY @ Включил. И они проходят, потому что теперь тестируют методы нового класса. Я таки не понимаю, что тебя не устраивает: тесты проходят, значит поведение осталось корректым. Если тесты проходят, но поведение некорректно, значит тесты некорректны. Давай пример кодом: как было до рефакторинга, как стало и что не так, а то я что-то не могу понять, на что ты жалуешься. |
Сообщ.
#165
,
|
|
|
Цитата korvin @ Зачем? На эти методы можно натравить имеющиеся тесты. Тест должен тестировать класс целиком, а не только новые (по сравнению с базовым классом) методы. |