class TestClass {
constructor(name: string, private address: string, public city) { }
testMethod() {
console.log(this.name) // Compiler error: Property 'name' does not exist on type 'TestClass'.
console.log(this.address);
console.log(this.city);
}
}
const testClass = new TestClass('Jane Doe', '123 Main St.', 'Cityville');
testClass.testMethod();
console.log(testClass.name); // Compiler error: Property 'name' does not exist on type 'TestClass'.
console.log(testClass.address); // Compiler error: 'address' is private and only accessible within class 'TestClass'.
console.log(testClass.city);
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
AA>>Зачем public?
S> А чтобы понимать, что это свойство. Оно может быть и не публичным
а если свойств будет сто штук, их нужно все будет в конструкторе перечислять? а если только часть из них нужно инициализировать? как по мне, все таки удобнее традиционный путь
class Foo {
public Property1
private Property2
...
public Property100
}
var foo = new Foo { Property1 = 1, Property100 = 100 } // инициализируешь только те свойства, которые считаешь нужным
Z>а если свойств будет сто штук, их нужно все будет в конструкторе перечислять? как по мне, все таки удобнее традиционный путь
Z>
Z>class Foo {
Z> public Property1
Z> private Property2
Z> ...
Z> Public Property100
Z>}
Z>var foo = new Foo { Property1 = 1, Property100 = 100 } // инициализируешь только те свойства, которые считаешь нужным
Z>
Нет конечно. Ты так же можешь их в классе прописать.
Просто здесь экономия на публикации свойств.
Кроме того конструктор выполняет не только установку свойств. https://metanit.com/web/typescript/3.1.php
и солнце б утром не вставало, когда бы не было меня
Z>опять так, сравниваем синтаксис создания списка по заданному диапазону в свифте Z>
Z>(200...299)
Z>
Z>против сишарпа
Z>
Z>Enumerable.Range(200, 299)
Z>
Вы чего с ума сошли проверять попадание в диапазон через Enumerable.
Тут помоему единственное нормальное решение — if ( code >= 200 && code <= 299 )
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Споришь.
IID>Напомню контекст: IID>1) изначально я говорил о числе устройств, доходы притащили вы
ПРитащили потому что число устройств, как оказывается, еще не самое главное.
IID>2) также я не спорил с тем, что в Эппле умеют доить более качественно
Ты на полном серьезе считаешь, что все 100% "worldwide gross revenue" от мобильных приложений идут Эпплу? И все 100% Worldwide Gross Mobile Revenue идут ему же?
IID>2) ты пытался доказать, что проиозводимая устройство прибыль коррелирует с ценой устройства (подтекстом — с обеспеченностью владельца). Это неверно, по обоим пунктам.
Здравствуйте, IID, Вы писали:
IID>fixed
Да сколько ни чини, все вменяемые люди под термином "выстрелил" по отношению к продукту понимают финансовую отдачу.
Если верить вашей статистике о том, что iOS устройств в 10 раз меньше, чем Android, то с учётом неумолимого графика, приведённого Mamut, выходит, что каждый пользователь iOS приносит разработчикам приложений в 12 раз больше денег, чем пользователь Андроида.
Это как бы полностью опровергает смелые предположения о том, что "на самом деле нищие пользователи хуавья платят больше денег за приложения, а пользователи эпла отдали последние штаны и кроме вацапа ничего не качают".
Поэтому лучше подобные идеи в ближайшие годы (до обновления статистики) публично не высказывать — засмеют.
Если хочется выступить в защиту андроида, то нужно делать это аккуратно, например так: "несмотря на более низкую ARPU андроид-устройств по сравнению с устройствами на iOS, в последние годы рост продаж этих устройств в значительной мере скомпенсировал этот перекос. Поэтому сегмент android-приложений постепенно догоняет по объёму сегмент iOS-приложений, что мотивирует разработчиков шире пользоваться кросс-платформенными фреймворками для удешевления входа в оба сегмента".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, okon, Вы писали: O>Тут помоему единственное нормальное решение — if ( code >= 200 && code <= 299 )
Ну, так там же главное — доказать превосходство Swift. Тут никакое враньё не будет чрезмерным.
А нормальных решений там и так накидали. Причём и синтаксически, оказывается, можно свифт превзойти.
Ну, и как бы сам пример показательный — в нормальном коллективе такой код ревью не пройдёт; потому что магические константы и диапазоны. Единственный верный вариант привёл Mamut — тот, где IsSuccesfullResponse. Потому что он единственный остаётся понятен и через 10 лет после увольнения автора, и даже новичку, который протокол HTTP впервые видит (и о соглашении про 2xx в жизни не слыхал).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, CreatorCray, Вы писали:
S>>>В последнее время выстрелили мобильные предложения. А там рулит Ява. TSP>>В геймдеве популярен Unity. А там C# CC>Для сравнительно небольших проектов. Потом упираются в ресурсы.
Это давно не так, на Unity делают triple-A игры.
Навскидку: Сities:Skylines c тысячами человечков-автомобилей, шарящихся на карте в реальном времени, никто никуда не упирается и очень приятно выглядит.
А это 2015 год.
На Юнити разве что шутеров не вспомню, да и то на PC, потому что в мобильном сегменте сейчас всех рвёт Call of Duty: Mobile.
Который, внезапно, тоже на Unity.
Здравствуйте, Max Mustermann, Вы писали: MM>Это давно не так, на Unity делают triple-A игры.
Ты похоже значение этого термина не понимаешь.
Triple A games (also known as AAA) are simple games (console or PC) that were developed under the highest development budget of that current time AND are highest promoted.
MM>шарящихся на карте в реальном времени, никто никуда не упирается
Обсчёт логики CPU-bound и не зависит от рендерера (Unity) MM>и очень приятно выглядит.
Мнээээ... Разишо издали.
Здравствуйте, Ватакуси, Вы писали:
В>Даже в первую десятку не входит по популярности запросов Гугл.
На основе запросов в гугл JS менее популярен, нежели C#.
В>Весь крупняк (на основе моего опыта и моих знакомых, конечно), или перешёл или переходит с .NET.
Здравствуйте, Ватакуси, Вы писали:
C0x>>А с чего ты взял что у .net падение популярности?
В>Даже в первую десятку не входит по популярности запросов Гугл. В>Весь крупняк (на основе моего опыта и моих знакомых, конечно), или перешёл или переходит с .NET. Это 3 банка из первый пятёрки и очень крупные мировые программерские конторы. Так же гос. учереждения (размером с министерство) в странах ЕС.
Не понимаю а в чем смысл то переходить? Куча библиотек, куча опенсорса. Приложения можно ваять на любую тему. В десктопе так вообще альтернативы нет. Сервера сейчас можно на .net Core ваять.видел вакансии на F#. Это конечно может и не си# но в тот же .net.
Здравствуйте, Mamut, Вы писали:
M>Java эволюционирует медленнее потому что у нее гораздо больше груз обратной совместимости.
Неа. С# до сих пор на 100% backward compatible (за исключением некоторых очень тонких моментов). Java эволюционировала медленно сначала из-за старпера Гослинга, а потом в силу того что у шарпа решения принимает сравнительно маленький language design team, а в Java этот процесс вовлекает большое количество народу.
Здравствуйте, Sinclair, Вы писали:
S>То есть никакой распаковки в новую переменную не требуется, как и магии с x = x: S>
S>public static int Foo(string? firstName, string? lastName)
S>{
S> if(firstName == null) throw new ArgumentException(nameof(firstName));
S> return
S> firstName.Length + // здесь warning-а нету: firstName is non-null
S> lastName.Length + // а здесь - есть.
S> 1;
S>}
S>
public static int Foo(string? firstName, string? lastName) =>
firstName == null
? throw new ArgumentException(nameof(firstName));
: firstName.Length + // здесь warning-а нету: firstName is non-null
lastName.Length + // а здесь - есть.
1;
Здравствуйте, Mamut, Вы писали:
M>То есть чтобы было понятнее: Swift — единственный в мире язык со «парадигмой строгой типизации, который не допускает своевольничания и предположений», в котором переменная внутри scope'а меняет тип в зависимости от того, участвовала она внутри присваивания в определенной конструкцией или не участвовала.
Справедливости ради в шарпе есть похожая ситуация, когда async у метода меняет тип return с Task<T> на T.