и это все? а спецификации того как работает IIS, ASP, WinForms, MTS и т.д. и т.п.? где официальные тесты, позволяющие сертифицировать альтернативную реализацию на соответствие стандарту? кто владеет правами на эти стандарты и гарантирует совместимость снизу вверх? кто учавствует в их разработке?
N>>тем не менее спрос на nonmicrosoft/nonintel весьма широкий. _>Ну и что? "За двумя зайцами погонишься — ни одного не поймаешь."
Жаба легко и непринужденно работает везде. куча софта работает под всеми популярными платформами и очень многие значительно лучше чем софт от MS (скажем, Oracle, SAP и т.п.). собственно, поддержка многих платформ по большому счету не требует невероятного кол-ва ресурсов, в отличае от попытки проникнуть на все рынки подряд грубо воруя чужие идеи, выпуская сырые и кривые продукты, опираясь только на маркетинг. думаю, если бы MS тихо и спокойно развивал desktop OS и офисный пакет его финансовые показатели были бы намного лучше а продукты выходили бы вовремя и без урезания бОльшей части планируемых фич. кстати, думаю что после ухода Билли на пенсию контору распилят на части и все станет на свои места.
N>>кроме того — политика мс подавляет конкурирующие сторонние решения. _>Хочется тебя огорчить — любая коммерческая организация стремится обойти конкурентов.
обойти — да. но монополизироваты рынок — далеко не всякая. Sun например, создала рынок J2EE серверов приложений, но сама на нем присутствует только с референсной (бесплатной) реализацией. и это только на пользу платформы в целом — разные реализации имеют разные плюсы, можно выбирать ту, которая больше подходит под конкретный продукт. ну, и конкуренция м/у вендорами приводит к тому что продукты в целом более качественны. рынка аналогов IIS/ASP небудет никогда т.к. MS его подавляет искуственно.
N>>нее... там намного более хитрые вещи чем тривиальные мьютексы. _>Какие?
нетривиальное из того, что я использую: ConcurrentHashMap, ConcurrentLinkedQueue, CopyOnWriteArraySet, CyclicBarrier, CountDownLatch, Exchanger, Executor, ScheduledThreadPoolExecutor, AtomicReferenceFieldUpdater, AtomicMarkableReference
большинство из этого можно сделать так или иначе на .NET, но нужно очень и очень глубоко вникать в memory model, большой объем работы по peer review и тестированию.
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, anton_t, Вы писали:
N>Жаба легко и непринужденно работает везде. куча софта работает под всеми популярными платформами и очень многие значительно лучше чем софт от MS (скажем, Oracle, SAP и т.п.).
По крайней мере на винде .NET удобнее.
N>собственно, поддержка многих платформ по большому счету не требует невероятного кол-ва ресурсов, в отличае от попытки проникнуть на все рынки подряд грубо воруя чужие идеи, выпуская сырые и кривые продукты, опираясь только на маркетинг.
А как там XMLDOM в Java, уже без глюков работает?
N>думаю, если бы MS тихо и спокойно развивал desktop OS и офисный пакет его финансовые показатели были бы намного лучше а продукты выходили бы вовремя и без урезания бОльшей части планируемых фич. кстати, думаю что после ухода Билли на пенсию контору распилят на части и все станет на свои места.
Ну прям гений маркетинга
N>>>кроме того — политика мс подавляет конкурирующие сторонние решения. _>>Хочется тебя огорчить — любая коммерческая организация стремится обойти конкурентов.
N>обойти — да. но монополизироваты рынок — далеко не всякая. Sun например, создала рынок J2EE серверов приложений, но сама на нем присутствует только с референсной (бесплатной) реализацией. и это только на пользу платформы в целом — разные реализации имеют разные плюсы, можно выбирать ту, которая больше подходит под конкретный продукт. ну, и конкуренция м/у вендорами приводит к тому что продукты в целом более качественны. рынка аналогов IIS/ASP небудет никогда т.к. MS его подавляет искуственно.
Если бы Microsoft не продвигала активно .NET, то Java бы его задавила по праву первого.
N>>>нее... там намного более хитрые вещи чем тривиальные мьютексы. _>>Какие?
N>нетривиальное из того, что я использую: ConcurrentHashMap, ConcurrentLinkedQueue, CopyOnWriteArraySet, CyclicBarrier, CountDownLatch, Exchanger, Executor, ScheduledThreadPoolExecutor, AtomicReferenceFieldUpdater, AtomicMarkableReference
N>большинство из этого можно сделать так или иначе на .NET, но нужно очень и очень глубоко вникать в memory model, большой объем работы по peer review и тестированию.
S>public class TreeNode
S>{
S> public IEnumerable<TreeNode> Children
S> {
S> get
S> {
S> return _children;
S> }
S> }
S> private List<TreeNode> _children = new List<TreeNode>;
S> // внимание, пошел трюк:
S> public IEnumerable<TreeNode> AllChildren
S> {
S> get
S> {
S> foreach(TreeNode child in Children)
S> {
S> yield return child;
S> foreach(TreeNode descendant in child.AllChildren)
S> yield return descendant;
S> }
S> }
S> }
S>}
S>
S>Покажи мне, как это здорово делается на Java.
ну, собственно никто не спорит — штука неплохая, но, реального value от нее не так уж и много. можно, например, так:
public class TestTree {
public static interface Closure<T> {
public void execute(T object);
}
public static class TreeNode {
private List<TreeNode> children = new ArrayList<TreeNode>();
public void traverse(Closure<TreeNode> closure) {
closure.execute(this);
for (TreeNode child : children) child.traverse(closure);
}
}
public static void main(String [] args) {
new TreeNode().traverse(new Closure<TreeNode>() {
public void execute(TreeNode object) {
System.out.println(object);
}
});
}
}
Здравствуйте, anton_t, Вы писали:
_>По крайней мере на винде .NET удобнее.
ну с такой постановкой вопроса практически согласен, с одной поправкой — только для десктопных приложений (которые конечно хороши, но все большая популярность тонких клиентов наводит на размышления).
_>А как там XMLDOM в Java, уже без глюков работает?
вообще, есть десяток реализаций DOM/SAX для Java, есть и более продвинутые/быстрые API (StAX, etc). а для .NET кто-то это делает? или MS демотивирует — мол есть наша им и пользуйся?
_>Ну прям гений маркетинга
а ты сам посмотри — от всего кроме винды и офиса по большей части одни убытки у них... влучшем случае в ноль выходят.
_>Если бы Microsoft не продвигала активно .NET, то Java бы его задавила по праву первого.
это прекрасно что .NET появился (для конкуренции), но на основе того что там есть yield (delegate, etc что достаточно просто делается без расширения языка) утверждать что он лучше... причем отметая намного более серьезные аргументы (да одни тонкие настройки ЖЦ гораздо более полезны чем все доп конструкции C# вместе взятые т.к. это никакими конструкциям в коде не заменить)...
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, anton_t, Вы писали:
_>>По крайней мере на винде .NET удобнее.
N>ну с такой постановкой вопроса практически согласен, с одной поправкой — только для десктопных приложений (которые конечно хороши, но все большая популярность тонких клиентов наводит на размышления).
Спорная поправка.
_>>А как там XMLDOM в Java, уже без глюков работает?
N>вообще, есть десяток реализаций DOM/SAX для Java, есть и более продвинутые/быстрые API (StAX, etc). а для .NET кто-то это делает? или MS демотивирует — мол есть наша им и пользуйся?
А зачем изобретать велосипед, если то что есть отлично работает? Как Microsoft может мне запретить сделать свою реализацию DOMXML?
_>>Ну прям гений маркетинга
N>а ты сам посмотри — от всего кроме винды и офиса по большей части одни убытки у них... влучшем случае в ноль выходят.
Люди, наверное, о будущем думают.
_>>Если бы Microsoft не продвигала активно .NET, то Java бы его задавила по праву первого.
N>это прекрасно что .NET появился (для конкуренции), но на основе того что там есть yield (delegate, etc что достаточно просто делается без расширения языка) утверждать что он лучше... причем отметая намного более серьезные аргументы (да одни тонкие настройки ЖЦ гораздо более полезны чем все доп конструкции C# вместе взятые т.к. это никакими конструкциям в коде не заменить)...
Тут уже приводили преимущества .NET, поищи в этом топике.
Здравствуйте, anton_t, Вы писали:
_>А зачем изобретать велосипед, если то что есть отлично работает? Как Microsoft может мне запретить сделать свою реализацию DOMXML?
например, для того чтобы быстрее работало. или для того чтобы поддержать более новую версию стандарта пока Sun не проапдейтит JDK. всякие новомодные легкие потоковые парсеры XML работают в разы быстрее DOM. MS не запретит, но исходя из идеалогии исходящей от MS этим парсером просто не будут пользоватся а будут ждать .NET 3.0 если есть проблемы во второй версии. кстати, исходники .NET DOM открыты или нет? на их основе можно что-нить делать?
_>Люди, наверное, о будущем думают.
в итоге превращают контору в монстра занимающимся всем и вся. как следствие недостаточное внимание к core products. о будующем подумают и другие, Гугл, например, у него, ИМХО, лучше получается.
_>Тут уже приводили преимущества .NET, поищи в этом топике.
так они все либо направлены на поддержку COM либо аналогичны по сути yield. ничего фундаментального (т.е. того что невозможно исправить простейшим расширением языка/рантайма) я не увидел. кстати, одно время generics были только в виде спецификации, но людям хотелось побыстрее их получить и имел довольно широкое распространение плагин к компилятору их реализующий (в силу закрытости компилятора для .NET, скорее всего, такое сделать нельзя, как насчет плагина с checked exceptions?).
если кому-нибудь всерьез был бы нужен yield/delegate/fixed/etc давно бы уже сделали аналогичный плагин, но это просто в голову никому не приходит т.к. можно сделать все тоже самое с помощью простых аналогов...
Здравствуйте, n0name2, Вы писали:
N>ну, собственно никто не спорит — штука неплохая, но, реального value от нее не так уж и много. можно, например, так:
N>
N>public class TestTree {
N> public static interface Closure<T> {
N> public void execute(T object);
N> }
N> public static class TreeNode {
N> private List<TreeNode> children = new ArrayList<TreeNode>();
N> public void traverse(Closure<TreeNode> closure) {
N> closure.execute(this);
N> for (TreeNode child : children) child.traverse(closure);
N> }
N> }
N> public static void main(String [] args) {
N> new TreeNode().traverse(new Closure<TreeNode>() {
N> public void execute(TreeNode object) {
N> System.out.println(object);
N> }
N> });
N> }
N>}
N>
Неа. Так — нельзя. У нас уже есть готовый метод, который принимает на вход IEnumerable<T>. Ты схитрил, и вместо итератора реализовал вызов замыкания. У нас базовым примитивом является не фрагмент кода, а итератор. Так что, пожалуйста, перепиши код так, чтобы реализовать именно итератор.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Неа. Так — нельзя. У нас уже есть готовый метод, который принимает на вход IEnumerable<T>. Ты схитрил, и вместо итератора реализовал вызов замыкания. У нас базовым примитивом является не фрагмент кода, а итератор. Так что, пожалуйста, перепиши код так, чтобы реализовать именно итератор.
я согласен с тобой — итератор будет сделать относительно сложно. хотя, в java.util.TreeMap такой имеется и занимает, ну, пусть 30 строк (приводить не буду, с твоего позволения, ничего примечательного там нет).
но я не согласен что так нельзя. чем замыкание хуже итератора? по сути задача решена, причем весьма просто.
если где-то есть какой-то legacy код (неприкосновенный) и есть задача вроде обхода дерева когда итератор без yield написать сложно, то для него можно один раз в жизни написать итератор (переиспользуемый). чаще чем раз в 20 лет не думаю что такая комбинация условий выпадет простому программеру.
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, Sinclair, Вы писали:
S>>Неа. Так — нельзя. У нас уже есть готовый метод, который принимает на вход IEnumerable<T>. Ты схитрил, и вместо итератора реализовал вызов замыкания. У нас базовым примитивом является не фрагмент кода, а итератор. Так что, пожалуйста, перепиши код так, чтобы реализовать именно итератор.
N>я согласен с тобой — итератор будет сделать относительно сложно. хотя, в java.util.TreeMap такой имеется и занимает, ну, пусть 30 строк (приводить не буду, с твоего позволения, ничего примечательного там нет).
N>но я не согласен что так нельзя. чем замыкание хуже итератора? по сути задача решена, причем весьма просто.
Нет! Задача никак не решена. Дело в том, что в отличие от замыкания, итератор можно трансформировать. Вот, например, я пишу фильтр на итераторах:
public static IEnumerable<T> FindAll<T>(IEnumerable<T> input, Predicate<T> predicate)
{
foreach(T item in input)
if (predicate(item))
yield return item;
}
Как ты его напишешь на замыканиях? N>если где-то есть какой-то legacy код (неприкосновенный)
Дело не в легаси. Дело в том, что итераторы я могу легко комбинировать. С замыканиями это намного сложнее. Если фильтр еще можно попытаться воспроизвести (хотя эффект будет не таким — фильтр придется применять не к исходной коллекции, а к замыканию), то с сортировкой как быть? У меня в CollectionHelper и такой метод есть:
/// <summary>
/// Sorts the input using the specified key
/// </summary>
/// <typeparam name="T">The type of the enumerable - normally may be omitted since
/// compiler derives it from the first argument</typeparam>
/// <typeparam name="TKey">The type of the key to perform comparison by. Must implement IComparable<TKey></typeparam>
/// <param name="collection">Source collection</param>
/// <param name="by">The key expression</param>
/// <returns>Array sorted by </returns>public static T[] Sort<T, TKey>(IEnumerable<T> collection, Converter<T, TKey> by)
where TKey: IComparable<TKey>
{
return Sort(collection, delegate(T x, T y) { return by(x).CompareTo(by(y)); });
}
Вот как это может использоваться:
IEnumerable<TreeNode> filtered = CollectionHelper.FindAll(Tree.Nodes.Root.AllChildren, delegate(TreeNode tn) { return tn.Weight>10; });
foreach(TreeNode node in CollectionHelper.Sort(filtered, delegate(TreeNode tn) { return tn.Name; }))
{
Console.Write(node);
}
N> и есть задача вроде обхода дерева когда итератор без yield написать сложно, то для него можно один раз в жизни написать итератор (переиспользуемый). чаще чем раз в 20 лет не думаю что такая комбинация условий выпадет простому программеру.
И вот очень зря ты так думаешь. Потому, что вот такое дерево мы изобретаем ежедневно. Вот я запустил поиск по проекту — yield return используется в 26 файлах, лень считать сколько именно раз.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Дело не в легаси. Дело в том, что итераторы я могу легко комбинировать. С замыканиями это намного сложнее. Если фильтр еще можно попытаться воспроизвести (хотя эффект будет не таким — фильтр придется применять не к исходной коллекции, а к замыканию), то с сортировкой как быть?
public class TestTree {
public static interface Closure<T> {
public void execute(T object);
}
public static interface Predicate<T> {
public boolean evaluate(T object);
}
public static class TreeNode {
private List<TreeNode> children = new ArrayList<TreeNode>();
public void traverse(Closure<TreeNode> closure, Predicate<TreeNode> predicate) {
if (predicate.evaluate(this)) closure.execute(this);
for (TreeNode child : children) child.traverse(closure, predicate);
}
public void iterate(Closure<TreeNode> closure, Predicate<TreeNode> predicate, Comparator<TreeNode> comparator) {
final List<TreeNode> temp = new ArrayList<TreeNode>();
traverse(new Closure<TreeNode>() { public void execute(TreeNode object) { temp.add(object); } }, predicate);
Collections.sort(temp, comparator); for (TreeNode node : temp) closure.execute(node);
}
}
public static void main(String [] args) {
new TreeNode().iterate(
new Closure<TreeNode>() {
public void execute(TreeNode object) { System.out.println(object); }
},
new Predicate<TreeNode>() {
public boolean evaluate(TreeNode object) { return object != null; }
},
new Comparator<TreeNode>() {
public int compare(TreeNode x, TreeNode y) { return 0; }
});
}
}
например так... кстати, можно во время копирования и сортировку делать заодно (бинарным поиском). а вообще, я бы сделал LinkedTree, параллельно хранил бы элементы дерева в списке. заодно в виде бонуса получил бы упорядоченность по времени вставки (или по другому параметру) и быструю итерацию по массиву...
N>> и есть задача вроде обхода дерева когда итератор без yield написать сложно, то для него можно один раз в жизни написать итератор (переиспользуемый). чаще чем раз в 20 лет не думаю что такая комбинация условий выпадет простому программеру. S>И вот очень зря ты так думаешь. Потому, что вот такое дерево мы изобретаем ежедневно. Вот я запустил поиск по проекту — yield return используется в 26 файлах, лень считать сколько именно раз.
а что за деревья такие, если не секрет? каково там кол-во элементов? вот у меня поиск по слову tree не выдает ни одного совпадения. если они где и есть, то используются через SAX или connect by prior в Оракле...
Здравствуйте, n0name2, Вы писали:
S>>Дело не в легаси. Дело в том, что итераторы я могу легко комбинировать. С замыканиями это намного сложнее. Если фильтр еще можно попытаться воспроизвести (хотя эффект будет не таким — фильтр придется применять не к исходной коллекции, а к замыканию), то с сортировкой как быть?
N>например так... кстати, можно во время копирования и сортировку делать заодно (бинарным поиском). а вообще, я бы сделал LinkedTree, параллельно хранил бы элементы дерева в списке. заодно в виде бонуса получил бы упорядоченность по времени вставки (или по другому параметру) и быструю итерацию по массиву...
Вот это и плохо. То есть ты все то, что я бесплатно имею, единожды написав класс CollectionHelper для всех вообще коллекций, вынужден делать для каждого TreeNode.
N>>> и есть задача вроде обхода дерева когда итератор без yield написать сложно, то для него можно один раз в жизни написать итератор (переиспользуемый). чаще чем раз в 20 лет не думаю что такая комбинация условий выпадет простому программеру. S>>И вот очень зря ты так думаешь. Потому, что вот такое дерево мы изобретаем ежедневно. Вот я запустил поиск по проекту — yield return используется в 26 файлах, лень считать сколько именно раз.
N>а что за деревья такие, если не секрет? каково там кол-во элементов? вот у меня поиск по слову tree не выдает ни одного совпадения. если они где и есть, то используются через SAX или connect by prior в Оракле...
Site Map, структура файловой системы. Это только пример — коллекции не ограничиваются деревьями. Итератор — это очень мощная абстракция. См. напр. STL.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Вот это и плохо. То есть ты все то, что я бесплатно имею, единожды написав класс CollectionHelper для всех вообще коллекций, вынужден делать для каждого TreeNode.
во-первых это я просто в примере написал iterate() как метод внутри TreeNode, собственно это можно вынести в Helper легко. во-вторых, зачем делать много TreeNode если можно сделать один универсальный?
S>Site Map, структура файловой системы. Это только пример — коллекции не ограничиваются деревьями. Итератор — это очень мощная абстракция. См. напр. STL.
и только немногие из них, ИМХО, относительно сложно написать без yield, кстати, STL отлично без этого справляется.
короче. yield штука полезная, изредка. но рассматривать это как некое приемущество дотнета я бы не стал, ну, так, интересная особенность языка... честно говоря, на месте Sun я не стал бы это включать в язык только потому что ввод нового ключевого слова может отразится на совместимости.
кроме того, есть библиотека классов Generic Algorithms for Java, в т.ч. готовые итераторы (с фильтрацией, объеденение двух и более, возвращающие только уникальные значения и т.д. и т.п.) на ВСЕ случаи жизни. честно говоря, ни разу не сталкивался с потребностью написать что-то не укладывающееся в ее концепции.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, n0name2, Вы писали:
_>>>yield делает сложное более простым. С чего вы взяли, что ты сможешь сделать проще и эффективнее без yield, чем с yield? Последний раз на прошлой неделе писал, а что? N>>пример конкретной задачи, если не сложно. про count%2 уже понял — делается элементарно. S>Вот класс элемента дерева с поддержкой обхода всех детей: S>
S>public class TreeNode
S>{
S> public IEnumerable<TreeNode> Children
S> {
S> get
S> {
S> return _children;
S> }
S> }
S> private List<TreeNode> _children = new List<TreeNode>;
S> // внимание, пошел трюк:
S> public IEnumerable<TreeNode> AllChildren
S> {
S> get
S> {
S> foreach(TreeNode child in Children)
S> {
S> yield return child;
S> foreach(TreeNode descendant in child.AllChildren)
S> yield return descendant;
S> }
S> }
S> }
S>}
S>
S>Покажи мне, как это здорово делается на Java.
Предупреждаю сразу не компилировал, но работать должно. Жду гнилых помидоров
public class TreeNode implements Iterable<TreeNode> {
private List<TreeNode> childrens = new ArrayList<TreeNode>();
public Iterator<TreeNode> iterator() {
return childrens.iterator();
}
public Iterator<TreeNode> getAllChildrens() {
MultiIterator<TreeNode> it = new MultiIterator<TreeNode>();
for(TreeNode child : this) {
it.addIterator(child.getAllChildrens());
}
}
public static class MultiIterator implements Iterator<TreeNode> {
private List<Iterator<TreeNode>> iterators = new ArrayList<Iterator<TreeNode>>();
int i = 0;
public void addIterator(Iterator<TreeNode> it) {
iterators.add(it);
}
public TreeNode next() {
if(hasNext()) {
return iterators.get(i).next();
}
throw NoSuchElementFound();
}
public boolean hasNext() {
while(i < iterators.size())
if(iterators.get(i).hasNext()) {
return true;
}
i++;
}
retun false;
}
}
}
Здравствуйте, Loafer, Вы писали: S>>Покажи мне, как это здорово делается на Java. L>Предупреждаю сразу не компилировал, но работать должно. Жду гнилых помидоров
public class TreeNode implements Iterable<TreeNode> {
private List<TreeNode> childrens = new ArrayList<TreeNode>();
public Iterator<TreeNode> iterator() {
return childrens.iterator();
}
public Iterator<TreeNode> getAllChildrens() {
MultiIterator<TreeNode> it = new MultiIterator<TreeNode>();
for(TreeNode child : this) {
it.addIterator(child.getAllChildrens());
}
return it; // надо полагать?
}
Прекрасная идея. В отличие от тупикового пути с замыканиями.
Есть только одно "но": в отличие от дотнетной, эта реализация не "ленивая". Т.е. первое же обращение к Tree.getRoot().getAllChildren() приведет к почти полному обходу дерева — кроме листьев. Прелесть yield в том, что он исполняется по мере необходимости. К примеру, если я делаю CollectionHelper.Find(Tree.Root.AllChildren, ...), то обход прекратится сразу же, как только я найду нужный элемент.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, n0name2, Вы писали:
N>во-первых это я просто в примере написал iterate() как метод внутри TreeNode, собственно это можно вынести в Helper легко.
Гм. Ты не мог бы показать, как именно это сделать? Причем желательно, чтобы iterate() не зависел от TreeNode. N> во-вторых, зачем делать много TreeNode если можно сделать один универсальный?
S>>Site Map, структура файловой системы. Это только пример — коллекции не ограничиваются деревьями. Итератор — это очень мощная абстракция. См. напр. STL.
N>и только немногие из них, ИМХО, относительно сложно написать без yield, кстати, STL отлично без этого справляется.
Гм. Ничего сложного, конечно, нет. Просто для того, чтобы написать каждый способ получения итератора, нужно как минимум два класса. Один — реализующий собственно итератор, и второй, отдающий этот класс. Вместо трех строчек получаем тридцать.
N>короче. yield штука полезная, изредка. но рассматривать это как некое приемущество дотнета я бы не стал, ну, так, интересная особенность языка... честно говоря, на месте Sun я не стал бы это включать в язык только потому что ввод нового ключевого слова может отразится на совместимости.
N>кроме того, есть библиотека классов Generic Algorithms for Java, в т.ч. готовые итераторы (с фильтрацией, объеденение двух и более, возвращающие только уникальные значения и т.д. и т.п.) на ВСЕ случаи жизни. честно говоря, ни разу не сталкивался с потребностью написать что-то не укладывающееся в ее концепции.
Ок. Нельзя ли продемонстрировать применение такого механизма для выдачи, допустим, хотя бы тех же листьев дерева, отобранных по условию?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали:
VD>>Gregory_krovosos сравнивал Шарп с Явой как языки и как рантайм подсистемы. Так что мой вопрос остается в силе. Что полезного в Яве в этом смылсе, чего нет в дотнете? S>Дотнета нет ни под одной другой осью кроме семейства Windows.
Вот вам, дорогой вы наш, .Net под:
Mac OS X
SUSE Linux (x86/x86-64/IA64/S390)
RedHat Linux (x86/x86-64/IA64/S390)
Здравствуйте, Azix, Вы писали:
A>Здравствуйте, Sheridan, Вы писали:
VD>>>Gregory_krovosos сравнивал Шарп с Явой как языки и как рантайм подсистемы. Так что мой вопрос остается в силе. Что полезного в Яве в этом смылсе, чего нет в дотнете? S>>Дотнета нет ни под одной другой осью кроме семейства Windows.
A>Вот вам, дорогой вы наш, .Net под: A>Mac OS X A>SUSE Linux (x86/x86-64/IA64/S390) A>RedHat Linux (x86/x86-64/IA64/S390)
A>http://www.mono-project.com/Downloads
A>Под Solaris нету, извините, там Java.
Здравствуйте, Azix, Вы писали:
A>Вот вам, дорогой вы наш, .Net под: A>Mac OS X A>SUSE Linux (x86/x86-64/IA64/S390) A>RedHat Linux (x86/x86-64/IA64/S390)
A>http://www.mono-project.com/Downloads
Гоаорят — малое подобие левой руки.
[RSDN@Home][1.2.0][alpha][621]
[Кто не знает, что такое мир, не знает, где он сам... [Марк Аврелий]]
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Azix, Вы писали:
A>>Вот вам, дорогой вы наш, .Net под: A>>Mac OS X A>>SUSE Linux (x86/x86-64/IA64/S390) A>>RedHat Linux (x86/x86-64/IA64/S390)
A>>http://www.mono-project.com/Downloads
S>Гоаорят — малое подобие левой руки.
Понятия не имею, что там гоаорят, но знаю — ВСЕ ЭТО РАБОТАЕТ, ОСНОВАНО НА Shared Source CLI Release (у MS тоже исходные коды выкладываются, иногда , основано на стандартах и спонсировано Novell.
Можно даже на сайте посмотреть список крупных корпоративных проектов, написанных на кросс-платформенной версии .Net.
Не думаю, что Java может предложить что-то похожее.