- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
/// <summary>
/// Return "Yes" for true and "No" for false
/// </summary>
public static string GetYesNoString(this bool val)
{
return val ? "Yes" : "No";
}
/// <summary>
/// Return "N/A" if no value, "Yes" for true and "No" for false
/// </summary>
public static string GetYesNoString(this object val)
{
if(val is bool)
return ((bool)val).GetYesNoString();
return "N/A";
}
Extension of the object class :) Very stupid because it make sense only for bool type, but it can be selected for every type in intellisense :)
Follow us!
Спасибо, Microsoft!
Существует множество методов обойти ограничения ООП (прототипирование, аспекты, мета программирование), и расширения -- самый топорный из них, превращающий ООП код в кашу.
Но Microsoft не виновато: у них задача: сделать интструмент, позволяющий быстро и легко делать софт без включения мозгов. И они с ней блестяще справляются.
Другой вопрос что поддерживать такие макароны почти нереально, но фишка в том, что это-то и не нужно!
Linq.Select("*").From("table").Where("a= 1");
Linq.Select(new Func<int, string>(input => input.ToString())).From....
Потом компилятор должен сравнить, можно ли вытащить из источника данных элементы типа int. Позиция MS в том, что естественный порядок написания запроса - сначала указывать, ОТКУДА выбираем, потом уже ЧТО именно. Что позволяет не писать явно new Func<int, string>(). Тип лямбды будет определен автоматически. Код становится короче и читабельнее.
А если кто-то забивает сковородкой гвозди -- то это уже его проблема.
Игрушечным пистолетом, который не навредит сотруднику полиции, или огнестрельным, из которого он сможет застрелиться?
:-)
а вот если бы выдавать каждому в целях самообороны - это ближе
Очень хорошая аналогия.
Программист -- это точно такая же профессия, как и полиция. Программист точно так же работает на благо общества.
У полиции свой отбор, у программистов -- свой.
ничего не понял)
можно пример?
Но, теоретически, может случиться так, что есть некоторый класс, который, скажем, предоставляет абстракцию общего назначения, имеет интерфейс, который содержит методы, которые в данной программе часто вызываются в определённой комбинации. (Тут нужно заменить: класс сам об этом не знает (!) это чисто из задачи программы данной получается ... то есть это не та ситуации, когда речь идёт о "стратегиях")
Например можно нафантазировать абстракцию файла. Его можно открыть, записать в него и закрыть. И скажем, нужно всё время захватывать файл, писать и отпускать. Тогда каждый вызов метода записи в файл в данной, конкретной программе может выглядеть так: obj.open(); obj.put(data); obj.close();
В C++ такая проблема легко разрешается созданием функции в программе, которая получает ссылку на объект, на котором нужно делать вызовы.
В языках с объектной парадигмой как основой, а не как инструментом, такая ситуация не разрешается прозрачно, потому что не ясно "куда добавить такой метод", который вообще говоря не добавляет функциональности. Если посмотреть внимательно на эту ситуацию, то любое её разрешение приведёт к неприятному коду. И вот "расширения" -- это самый простой способ с ними справиться.
Можно создавать закрытую статическую функцию класса программы, чтобы она сама её вызывала. Всяко можно... Но всё плохо.
Вы попой чуете, что это метод абстракции файла, а пихать приходится чёрти-куда.
А вот с расширениями у вас появляется точное место. Этот метод, хоть он левый получается, всё же, принадлежит именно абстракции файла, а не программе или интерфейсу какого-нибудь ещё типа.
можно пример?
public static class Tools{
public static void foo(Class target);
}
Example:
Class val = new Class();
Tools.foo(val);
When extensions are used, then the code change become to this:
public static class Tools{
public static void foo(this Class target);
}
Example:
Class val = new Class();
val.foo();
or
Tools.foo(val);
The only difference is syntax, and extensions works well with intellisense. You can make your extensions to sealed or primitive classes or make a lot of govnocode. The choice is yours :)
правильно. А еще можно рефлексией лазить в приватные свойства.
К черту архитектуру)
Но если даже и так то
у всех инстансов этого несчастного класса появляется этот метод GetYesNoString()
но ведь если это метод инстанса -- туда надо как-то передать ссылку на объект, верно?
вот в этом случае она и передается (this значит "ссылка на объект")
и тут Вы спросите: а почему же там bool?
а хрен его знает, наверное автовраппинг сработает
кстати в некоторых средах на низком уровне методы инстансов так и работают -- в них передается ссылка на объект
Знаю не по наслышке. :)
Вообще, если есть желание, Вы можете мне что-нибудь посоветовать, просто рассказать о своём идеальном языке кратко в возможностях. Можно на примере другого языка (методом исключения некоторых функций и добавлением новых (ваших желанных) (Рассказать в стиле, как говорил известный персоонаж Никулина:"Хочу такого коня, только без крыльев.") ). Ну или просто скажите, что-бы Вы хотели там видеть (одну самую любимую фишечку). Или посоветуйте посмотреть в сторону какого-то языка.
Может быть я их учту. :)
1) ловить несколько эксепшенов, например:
2) что бы было множественное наследование (иногда грустно, когда надо перегрузить один метод и делегировать 48): я вкурсе проблемы ромба, но все таки...
3) что бы была препроверка условий на нулл (например @NotNull login и теперь если передать null -- просто не скомпилируется).
4) видимость на все подпакеты (виден в этом пакете и всех внутри него)
это сходу)) а так -- надо подумать конечно
Ммм. Я уже начал делать вот так:
Хотя подумаю над вашим предложением...
2)>я вкурсе проблемы ромба
Множественное будет, но брилиантовую иерархию я собираюсь запретить.
3)3е не очень понял. Как это проверка на нуль во время компиляции? Может во время выполнения?
4)Поясните. Например, на примере кода.
Правда мне не нравится, что придёться проверять на null exception'ы, что бы определить от какого он произошёл. Если знаете, как разрулить ситуацию - жду совета. :)
Ловить пачкой можно только родственные эксепшены, и переменная должна быть типа их общего родителя.
Тоесть тут это IO (ибо сокет и FileNotFound -- потомки IO).
А вот что бы привести к конкретному типу -- или instanceof или visitor.
в этом блоке -- 2
в другом -- 2
итд
разумеется, тип мы знаем не всегда, но в таких махкровых случаях можно и ругаться.
4)
например у Вас есть пакет view. А у него два подпакета view.html и view.console.
а внутри view.html у Вас пакет view.html.jsp (для генерации через JSP) и view.html.xsl (для генерации через xsl). а внутри консоли есть пакет view.console.curses для псевдографики с использованием curses итд.
у Вас есть класс, который относится только к view.html (например там что-то для HTML). Какую ему видимость поставить? Если пакетную -- его не увидят во view.html.jsp. Если публичную -- его будет видно везде, где ненужно.
Хочется иерархии. Чем ближе к корню, тем более общие классы (от которых все зависят), так что логично сделать видимость на пакет и подпакеты.
А какой это профит даёт?
хотя это и можно описать в javadoc
вообще мысль моя сыра: надо обдумать, конечно)))
для нормальной работы моего класса, у него должно быть установлено N полей. Я не могу пихать их в конструктор по какой-то причине (у меня дураццкая сериализация, требующая parameterless конструктор, я -- бин, который должен иметь сеттеры итд).
и я хочу как-то сказать пользователю, что надо вот эти пять полей установить обязательно перед вызовом метода. Можно конечно проверить все самому, и кинуть ObjectNotConfiguredException , но хочется как-то это упростить
хотя я не знаю как тут язык поможет
Я подумаю..., но помоему это противоречит основным концепциям ООП?
@ -- это атрибут. В C# это было бы <NotNull> кажется
(2) -- нафиг. Даже в C++ это больше создаёт проблем (кроме наследования от чисто абстрактных классов, т.е. интерфейсов).
(4) -- поздно менять, да и не очень-то нужно.
1)Все "переменные" константные по умолчанию, кроме переменных для цикла for.
2)Можно добавить var и "переменная" становится переменной)))
3)Массивы, встроенные в язык, более функциональны, например всегда знают свою длину и их можно возвращать как результат функции.
4)Механизм потоков встроен в язык.
5)Каждый поток имеет свою копию переменных, в том числе глобальных.
6)Переменные могут стать общими для нескольких потоков, если объявлять их как shared.
7)Не знаю, вводить ли volatile (встроенная синхранизация перед обращением, к переменной)?
8)Планирую более декларативный for(кроме приплюснутого), чтото типа:
for (x to 10)
for (y = x downto 0)
for (x in list)
for (x = 1 when x % 2 == 0 to 10)
(реализован пока только приплюснутый).
Ну это основные планируемые отличия от С++. Возможно дальше придумаю больше, тк в планах "прикрутить" и функциональную парадигму (начало положено). Есть идейки о прикручивании некоторых возможностей из С#.
10)Сборщик мусора очень модный в наше время, но мне он что-то не нравится... Хочу иметь возможность использовать паттерн RAII нормально, хочу всегда детерминированное освобождение ресурсов (тк это часто источник ошибок у неопытных людей, пересевших на C#). (Впрочем отсутсвие сборщика - не меньшая причина ошибок...) Вообщем ещё пока не решил насчет сборщика (разве, что его пока нет ни в каком виде). Может есть какие идеи насчёт этого пункта? Может вообще не то и не другое выбрать? В прочем мне ничего не приходит в голову - чем это можно заменить...
Вообщем, что думаете насчёт этих пунктов? Конечно, понятно, что ничего выдающегося, но все же...
Может я делаю велосипед? Есть язык с похожими идеями?
Ах да. У него нет названия, пока. Ничего не приходит в голову... G# или G++ - как то банально... Так что можите предлагать. Я подумаю. Быть может, именно Ваше название станет во главе языка. :)
Имхо, любопытно. Возможно, вы уже видели этот материал; в частности, идея цикла for во многом совпадают.
По десятому пункту.
Да, RAII - это хорошо. Я пока далёк от создания своего языка, но думал об этом. Знаю, что в OS Singularity можно использовать разные сборщики мусора. Отталкиваясь от этой идеи, можно попробовать сделать разные GC для разных стратегий приложения, а также чтобы часть программы (модуль или нечто такое) могла работать без GC - тут уже можно реализовать RAII.
Вот этот цикл из Ela и взял.
>for (y = x downto 0)
Правда ещё думаю над их другой формой записи:
for (x -> 10)
for (y = x <- 0)
Может быть только один из этих 2х оставлю, а именно for (x -> 10), Тоесть стремиться будет лишь к определённому числу (неважно больше оно или меньше).
Это конечно источник неоднозначностей, поэтому видимо будет 2 формы
>to
и
>downto
,а не одна.
Это источник ошибок, боюсь... Был код с delete, потом решили, что в модуле будет использоваться сборщик, через какое-то время появились без delete'ов части модуля, но снова решили выпилить сборщик мусора... Вот тут придётся дописывать delete'ы... А если забыли, то фейл... Так и будет память утекать.
Я думаю завести 2 вида указателей - обычные и со сборкой мусора, но правда это что-то очень похоже на С++\cli...
и даже кажется их настраивать
Показалось, что идеи во многом совпадают с Common Lisp; в чем автор, впрочем, косвенно признается.
хочу Template Haskell c Dependent-types (хотя бы), а в идеале - все грани лямбда-куба. мммм.. вот этим я бы обмазался
Я начинал с императива. Теперь в сторону функциональности развиваюсь.
и еще: описано столько тонн сахара, но ни слова о каком-либо средстве для пидорашения AST. весь сахарок сразу в грамматике?
Поясните пожалуйста.
Пожалуй это самая интересная часть в языке. :)
а про раздувание самой грамматики
Если вы о моих распросах на говнокоде, то я не буду против, что-бы в моём языке что-то поменялось. Концепция ведь пока не законченная. Это лишь исследование возможных направлений. Проба пера.
Хоть я сейчас уже реализую в таком виде, но возможно дальше абсолютно всё поменяется.
Сколько раз уничтожал свой роман "Война и Мир" Лев Николаевич Толстой, прежде чем у него получилась конфетка?
Пока у меня не получится конфетка - я своё творение буду безжалостно уничтожать.
здесь получаются бессмысленные обходные маневры в тылу врага
Набью немного шишек. Это дело житейское.
Заказчик не ждёт, поэтому пока можно.