Rust vs C++ , очередная шляпа

Цитата Wound @ 27.08.19, 12:52

Да и флаг им в руки откуда они пришли. Хоть с марса, пиши:

Киля, это твое решение будет работать далеко не для любых param1 и param2. Почитай что-ли ссылки, которые я дал выше.

Цитата Wound @ 27.08.19, 12:52

Далее есть ArgumentList - который представляет из себя массив строк. Можешь прям в него запихать аргументы командной строки.

Цитата

Запрашиваемая страница недоступна для .NET Framework 4.8. Вы перенаправлены на последнюю версию продукта, для которой доступна эта страница.

Цитата applegame @ 27.08.19, 13:00

Запрашиваемая страница недоступна для .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

Добавлено 27.08.19, 13:16

Цитата applegame @ 27.08.19, 13:00

Киля, это твое решение будет работать далеко не для любых param1 и param2. Почитай что-ли ссылки, которые я дал выше.

Ну ты ведь должен понимать что ты вообще ожидаешь? Это все что ты говоришь - синтетическая выдумка. Ну живет же как то народ. Я тебе выше написал разные вариации на тему, как можно.

M

Ввиду незрелости топик-стартера в плане идеологии Раста на момент создания топика - предлагаю переместить священные войны по топику в тему "Rust vs Чистейший Си"

А что, тема себя изжила, что ли, и никому больше нечего тут сказать? JoeUser, ты может быть что-то для себя и решил ...невероятный случай для холивара... но тема куда ширее.

Добавлено 27.08.19, 17:28

Цитата applegame @ 27.08.19, 11:32

Суть:

Цитата applegame @ 27.08.19, 08:19

Ну вот есть у тебя список аргументов в виде массива строк, и надо вызвать стороннюю программу с этими аргументами. В аргументах есть пробелы и слеши/бэкслеши,

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

Задача нерешаема без указания особенностей целевого приложения. Я вот не уверен, что кавычек для экранирования ему хватит.

!

Qraizer, признаю свою ошибку и тему открываю!
Кому интересна тема раста и плюсов - вэлком сюда!
Тема без ООП есть рядом.
Простите, погорячился!

Цитата Qraizer @ 27.08.19, 17:27

Задача нерешаема без указания особенностей целевого приложения. Я вот не уверен, что кавычек для экранирования ему хватит.

Только кавычек однозначно не хватит, поэтому и пишут сложные регекспы. И почему это задача нерешаема, если ее давно уже решили.

Цитата D_KEY @ 27.08.19, 07:03

Подожди. Вот есть у тебя в классе A метод foo. С какой-то реализацией. Наследники переопределили. Override не написали. Потом ты рефакторишь A и меняешь сигнатуру метода. Во всех наследниках код будет валиден и компилятору не к чему придраться, хотя это ошибка. Где-то ты поправил сам(потому что помнил), где-то свалились тесты. А где-то это уехало на прод
Не?

Это фатальный недостаток ООП вообще и наследования в частности. :trollface:

Если у тебя после этого все тесты остались зелёными, то либо никакой ошибки и вправду нет, и всё работает корректно, либо у тебя дерьмовые тесты и более серъёзные проблемы. =)

Чуть позже распишу про «фатальный недостаток», далеко не уходи. =) Вкратце, он в использовании одной сущности для разных вещей (правильно, ведь зачем плодить сущности, если всё можно сделать одной мегауниверсальной сущностью, да?)

Цитата korvin @ 27.08.19, 18:49

Если у тебя после этого все тесты остались зелёными, то либо никакой ошибки и вправду нет, и всё работает корректно, либо у тебя дерьмовые тесты и более серъёзные проблемы. =)

Ну почему? Они же, вероятно, как раз дергают методы класса, который тестируют, а не базового класса, и это нормально. И такие тесты будут продолжать проходить.

Цитата applegame @ 27.08.19, 18:43

И почему это задача нерешаема, если ее давно уже решили.

Сиречь придумали универсальный протокол, придерживаться которого должны обе стороны.Ага?

Цитата D_KEY @ 27.08.19, 07:03

Подожди.

Вот смотри, рассмотрим сначала на примере интерфейсов и 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…

Добавлено 27.08.19, 20:14

Цитата D_KEY @ 27.08.19, 19:28

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

Значит и использование классов продолжить быть корректной. В чём проблема?

Сообщение отредактировано: korvin - 27.08.19, 20:22

Цитата korvin @ 27.08.19, 20:13

Значит и использование классов будет продолжать быть корректным.

При использовании через базовый класс/интерфейс не будет

Портянки твои завтра уже прочитаю скорее всего

Цитата D_KEY @ 27.08.19, 20:17

При использовании через базовый класс/интерфейс не будет

Ты не включил в тесты производного класса тестирование методов из базового? Плохой тест. Тест должен тестировать класс целиком, а не только новые (по сравнению с базовым классом) методы. Плохие тесты.

Цитата korvin @ 27.08.19, 20:24

Ты не включил в тесты производного класса тестирование методов из базового?

Включил. И они проходят, потому что теперь тестируют методы нового класса.

Цитата korvin @ 27.08.19, 20:13

…Продолжение последовало

Теперь выделим оба варианта в отдельные сущности следующим образом:
– для первого варианта будем использовать 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 грустновато.

Но это только интерфейсы, осталось разобрать наследование реализаций (классов)…

Добавлено 27.08.19, 21:28

Цитата D_KEY @ 27.08.19, 21:05

Включил. И они проходят, потому что теперь тестируют методы нового класса.

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

Давай пример кодом: как было до рефакторинга, как стало и что не так, а то я что-то не могу понять, на что ты жалуешься.

Цитата korvin @ 27.08.19, 20:24

Тест должен тестировать класс целиком, а не только новые (по сравнению с базовым классом) методы.

Зачем? На эти методы можно натравить имеющиеся тесты.