оператор with

← →
jack128_ (2011-07-02 23:04) [40]

> Чем то принципиально отличается?

да. Сложностью реализации iterator паттерна на дельфи. Пока в дельфи не появится yield - не взлетит.

← →
TUser © (2011-07-03 06:02) [41]

> _Юрий (02.07.11 12:18) [29]

А это кто так умеет? (Я, каюсь, застрял на уровне Делфи 7)

← →
Юрий Зотов © (2011-07-03 09:29) [42]

> cross (01.07.11 16:27)

> как вы относитесь к оператору with?
У нас одностороннее знакомство: я его знаю, он меня - нет.

> стоит ли его использовать?
Дело вкуса.

> хотелось бы услышать ваше мнение.
Я использую его в простых и коротких конструкциях, где он практически не влияет на читабельность. Иногда использую двойной with, но только там, где он наверняка не дает неоднозначности. И никогда - тройной и выше.

← →
_Юрий (2011-07-03 10:08) [43]

> jack128_ (02.07.11 23:04) [40]

> да. Сложностью реализации iterator паттерна на дельфи. Пока
> в дельфи не появится yield - не взлетит.

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

> TUser © (03.07.11 06:02) [41]
>
>

См. GetEnumerator
Не помню, с какой версии появился, но точно достаточно давно, возможно, что есть уже в D7

← →
DiamondShark © (2011-07-03 11:47) [44]

> jack128_ (02.07.11 23:04) [40]
> > Чем то принципиально отличается?
> да. Сложностью реализации
> iterator паттерна на дельфи. Пока в дельфи не появится yield
> - не взлетит.

В C# 1.0 yield не было, но итераторы как-то взлетали.
yield -- фигня.
Многие прогрессивные патерны не взлетят без автоматического управления памятью.

← →
DiamondShark © (2011-07-03 11:50) [45]

> _Юрий (02.07.11 12:18) [29]

Разумеется, не отличается. Все CLS-языки мало чем принципиально отличатся. Что и доказывает тезис о том, что дело не в with, а в совсем других языковых средствах, при наличии которых и with не особо-то и нужен.

← →
DiamondShark © (2011-07-03 12:01) [46]

> _Юрий (03.07.11 10:08) [43]
> Не вижу особых проблем,

class MyEnumerator : IEnumerator { MyElement m_Current; object IEnumerator.Current { get { return m_Current; } } bool IEnumerator.MoveNext() { if (AnyExternalCondition) m_Current = new MyElement(); else return false; return true; } }

А теперь вопрос: кто будет заниматься генерируемыми экземплярами в исполняющей среде без автоматического управления памятью?

← →
DiamondShark © (2011-07-03 12:04) [47]

> TUser © (03.07.11 06:02) [41]
> А это кто так умеет? (Я, каюсь, застрял на уровне Делфи 7)

С 2005 появилось.

← →
_Юрий (2011-07-03 13:15) [48]

> DiamondShark © (03.07.11 12:01) [46]
>
>

> А теперь вопрос: кто будет заниматься генерируемыми экземплярами
> в исполняющей среде без автоматического управления памятью?

Программист будет заниматься, какие варианты.
Можно поручить это итератору - запоминание предыдущего экземпляра, и его разрушение перед следущей итерацией, а последний разрушается вместе с самим итератором. Такой вариант у меня уже взлетел, просто пришлось подробно задокументировать поведение (разрушение или неразрушение идет в соответствии с переданным в конструктор итератора параметром). Слегка через задницу, но проблема решилась.
Впрочем, в большинстве случаев итерация не предполагает инстанцирования на кажлом шаге, и эта проблема не возникает вовсе.

ЗЫ, Если чего, я совершенно не отрицаю преимуществ, которые дает автоматическое управление памятью

← →
DiamondShark © (2011-07-03 14:07) [49]

> Впрочем, в большинстве случаев итерация не предполагает

В большинстве случаев, итерация (как, впрочем, вообще любая высокоуровневая конструкция) предполагает сокрытие деталей реализации.
У вас же все потроха наружу торчат.
Документируй, не документируй, а рано или поздно встретятся непонятно откуда взявшийся инстанс, про который есть только ссылка на интерфейс-енумератор и непонятно откуда взявшийся инстанс, про который есть только ссылка на интерфейс-консумер. И опачки.
Если вы реализуете интерфейс, то вы не имеете права требовать от клиента сакрального знания, сверх спецификации интерфейса.

← →
Дмитрий Тимохов (2011-07-03 20:18) [50]

Иногда пользую. Но редко.

Лучше через однобуквенные лок. переменные.

← →
Kerk © (2011-07-03 20:45) [51]

А почему однобуквенных-то? Символы экономишь? :)

Блин, не ветка, а сборник моих кошмаров :)

← →
Inovet © (2011-07-03 20:54) [52]

> [51] Kerk © (03.07.11 20:45)
> А почему однобуквенных-то?

Остальные цифры
а1, а11, а111112
:)

← →
Дмитрий Тимохов (2011-07-03 21:11) [53]

ну я оч. редко использую - очень. на 2млн строк написанных мною за жизь - места 3 всего...

← →
Игорь Шевченко © (2011-07-03 23:04) [54]

> на 2млн строк написанных мною за жизь

а как ты строки считаешь ?

← →
_Юрий (2011-07-03 23:13) [55]

> DiamondShark © (03.07.11 14:07) [49]
>
>

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

Такая деталь, как "что же нам вернулось - новый инстанс, или уже существующий" - вовсе не то, от чего следует абстрагироваться, неважно в каком языке. Вызывающая сторона должна четко понимать, что же она получила. По крайней мере в случаях, когда полученный экземпляр поддерживает изменение состояния.

Все прочие детали реализации сокрыты одинаково в обоих примерах.

← →
Anatoly Podgoretsky © (2011-07-03 23:30) [56]

> Игорь Шевченко (03.07.2011 23:04:54) [54]

1, 2, 3,...2 000 000

← →
Kerk © (2011-07-03 23:35) [57]

> _Юрий (03.07.11 23:13) [55]
> Такая деталь, как "что же нам вернулось - новый инстанс,
> или уже существующий" - вовсе не то, от чего следует абстрагироваться,
> неважно в каком языке. Вызывающая сторона должна четко
> понимать, что же она получила.

Принятие общего правила "я тебя породил, я тебя и убью" избавляет от подобной головной боли.

← →
Eraser © (2011-07-03 23:57) [58]

> [54] Игорь Шевченко © (03.07.11 23:04)

кстати, имеется ли какая-нибудь удобная утилита для подсчета строк в pas-файлах? Понимаю, что написать можно и самому, но скорее всего ведь есть готовые средства с простенькой статистикой.

← →
Anatoly Podgoretsky © (2011-07-04 00:25) [59]

> Eraser (03.07.2011 23:57:58) [58]

Посмотри у меня на сайте, в программах

← →
TUser © (2011-07-04 10:21) [60]

cat *.pas *.dpr | wc -l

нужен цигвин или линукс

← →
DiamondShark © (2011-07-04 10:33) [61]

> Kerk © (03.07.11 23:35) [57]
> Принятие общего правила "я тебя породил, я тебя и убью"
> избавляет от подобной головной боли.

Но рождает головную боль типа: "Кого считать породителем?"

interface IResourceManager { Stream GetResourceStream(string resourceName); }

Вопрос: кто "породил" стрим (а, следовательно, ответственнен за уничтожение), клиент, вызвавший GetResourceStream, или реализатор IResourceManager, который, собственно, и создал конкретный инстанс и вернул его как абстрактную ссылку клиенту?

← →
Anatoly Podgoretsky © (2011-07-04 10:59) [62]

> DiamondShark (04.07.2011 10:33:01) [61]

Version Information

--------------------------------------------------------------------------------

..NET Framework
Supported in: 4, 3.5, 3.0

Ответственнен за уничтожение .NET

← →
oxffff © (2011-07-04 12:03) [63]

> Ответственнен за уничтожение .NET

:)))))))))))))

← →
Inovet © (2011-07-04 12:11) [64]

> [63] oxffff © (04.07.11 12:03)
> > Ответственнен за уничтожение .NET
>
> :)))))))))))))

Джон Конар.

← →
oxffff © (2011-07-04 12:21) [65]

> Inovet © (04.07.11 12:11) [64]

:)

← →
Kerk © (2011-07-04 13:17) [66]

> DiamondShark © (04.07.11 10:33) [61]
>
>
> > Kerk © (03.07.11 23:35) [57]
> > Принятие общего правила "я тебя породил, я тебя и убью"
> > избавляет от подобной головной боли.
>
> Но рождает головную боль типа: "Кого считать породителем?
> "
>
> interface IResourceManager
> {
> Stream GetResourceStream(string resourceName);
> }
>

А чего тут думать-то? Надо просто правильно методы назвать.

interface IResourceManager { Stream GetResourceStream(string resourceName); Stream CreateResourceStream(string resourceName); }

> Игорь Шевченко (04.07.2011 14:53:07) [67]

оо?

> оо?

как в [60]

← →
_Юрий (2011-07-04 19:30) [70]

> Kerk © (03.07.11 23:35) [57]

> Принятие общего правила "я тебя породил, я тебя и убью"
> избавляет от подобной головной боли.
>

Это не всегда приемлимо. Например - стартуем короткую транзакцию, делаем выборку из базы, запоминаем список объектов, потом тут же закрывем транзакцию, а список оставляем себе.

В общем то, головной боли на самом деле никакой нет.

function TRepository.GetEnumerable<T>(AutoDestroyObjects: Boolean): IEnumerable<T>;

а дальше всего два варианта:

for MyModel in Repository.GetEnumerable<TMyModel>(True) do
//MyModel актуален только в течение итерации, указатель не запоминаем

for MyModel in Repository.GetEnumerable<TMyModel>(False) do
//необходимо запомнить указатель для дальнейшего разрушения

И все, никаких неоднозначностей.

> _Юрий (04.07.11 19:30) [70]

А в чем состоит задача?

← →
_Юрий (2011-07-04 20:53) [72]

> oxffff © (04.07.11 19:36) [71]
>
>

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

> _Юрий

выборка из базы и "запоминание" объектов и есть их порождение. несогласен?

> Eraser © (03.07.11 23:57) [58]

> кстати, имеется ли какая-нибудь удобная утилита для подсчета
> строк в pas-файлах?

CnWizards

← →
_Юрий (2011-07-04 23:26) [75]

> Palladin © (04.07.11 22:34) [73]

Из базы у нас возвращаются не объекты, а датасет. Порождением объектов приходится заниматься лично

> _Юрий (04.07.11 23:26) [75]

Ну и в чем проблема-то? Ты лично породил, ты лично и уничтожай.

> _Юрий (04.07.11 20:53) [72]
>
> > oxffff © (04.07.11 19:36) [71]
> >
> >
>
>
> задача состоит в том, чтобы не запутаться с разрушением
> объектов в случае, когда итератор на каждом шаге порождает
> новый объект.

А где путаница?

1. Например объект может предоставлять несколько енумераторов, по стратегии обхода, по стратегии принадлежности, т.е. параметр AutoDestroyObjects: Boolean не нужен.
2. Енумератор может освобождать объекты сам по окончанию своей работы.
3. Или может освобождать предыдущий объект после MoveNext на текущий.
4. GC
5. ....

← →
_Юрий (2011-07-05 20:21) [78]

> oxffff © (05.07.11 09:13) [77]

> А где путаница?

Я и говорю, что нет никакой путаницы. В ветке все написано, собственно.
Я просто рассказал о том, как сделал итератор, в ответ на

DiamondShark © (03.07.11 11:47) [44]
Многие прогрессивные патерны не взлетят без автоматического управления памятью.

Впрочем, утверждение в целом верное. Но итератор таки взлетел.

оператор with Найти похожие ветки