Re[3]: Чем вам всем не угодил Delphi? - Компьютерные священные войны

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, Ведмедь, Вы писали:

H>>>В смысле не обязывают? А эти конфиги упоминаемые тут для настройки ремотинга? Для пользователей любящих кофе давно есть клавы-"непромокайки"

, и даже буки такие есть

(видимо производитель счел, таки, недостатком

)

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

H>Вот и чудно что не обязывает. Какой вариант будет использован средним разработчик чаще всего? Посыл ясен?
Средний разработчик на Java и .NET будет использовать конфиги.
А на делфи — не будет. В делфи для этого средств маловато.
Можешь не спорить ибо .NET и Java ты не знаешь.

Здравствуйте, Сергей, Вы писали:

С>>>Прекрасно. Какие критерии сложности ты имел ввиду при этом?

kuj>>Никакие. Это оборот речи. Неужели у всех дельфятников так туго с пониманием?

С>Видимо, с пониманием смысла твоих сообщений туго не только у "дельфятников", поскольку к ним я не отношусь.
Ну-ну.
С>Ты бы поменьше использовал подобные обороты речи и побольше бы писал бы о том, что имеешь ввиду — глядишь, и понимать лучше начнут.

Я всегда пишу "о том, что имею в виду".

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, Ведмедь, Вы писали:

H>>>Я с Паскалем 13 лет. Спасибо.

В>>А у меня вопрос, а что-нибудь кроме паскаля за плечами есть? Или не читал, но осуждаю?

H>До паскаля много чего было, после него только Ada в ознакомительном режиме. Под .Net собирался, но не собрался. Я удовлетворил твой интерес к моей скромной персоне?
Сейчас 2008 год, когда ты начал заниматься паскалем был 1995, в то время в России мало чего было. Сейчас это уже все устарело.

H>>>Я тебе говорил про потерю ресурсов на dbconnection. Ты мне сказал, что FxCop тебе все покажет. Ы?

В>>Кстати хочу заметить, что ресурсы не потеряются, а будут освобождены только при следующей сборки мусора, что в условия ограниченного пула ресурсов может быть не приемлимо. Так что все равно со временем и файл и коннекция освободится... а в Паскале когда не освобожденный объект корректно освободится?

H>Со временем... С каким? Сутки? Двое? В нативе оно конечно не освободится, но у натива и посыл другой: взял -- верни. Глубина проблемы ясна?
Никто не мешает писать в стиле взял — верни в управляемых средах (на самом деле так писать даже лучше). С одной поправкой: в управляемых средах память не является таким ресурсом.
Где тут глубина проблемы?

Здравствуйте, gandjustas, Вы писали:

H>>Давай я пример приведу:

H>>

H>>...
H>>HttpProxy := client As IHttpProxy;
H>>SocksProxy := client As ISocksProxy;
H>>HttpHeaders := client As IHttpHeaders;
H>>

G>Что здесь не так?
G>Вполне корректный код как на делфи, так и на C# с точностью до синтаксиса.

Отлично

H>>Как по твоему, в случае приведения типа к объекту, client должен являться наследником и THttpProxy и TSocksProxy и THttpHeaders? Теперь понятно о чем речь?
G>Не понятно.

Мдя... Я устал твердить одно и тоже.

G>У любого класса базовый класс может быть только один. Это верно и для делфи, и для .NET, и для Java.
G>Соответственно приведение объекта к классу, не являющемуся базовым для типа объекта, вызвет ошибку или вернет null при использовании оператора as.

Я показал запрос интерфейса. Но ты ранее сказал, что мое решение основанное на интерфейсах это следствие кривизны Delphi. Я от тебя видимо уже не дождусь примера на запрос объекта, ибо ты сказал, что и на объектах можно все реализовать. Причем, отдавать объекты посредством свойств нельзя, ибо противоречит условиям задачи (сущность не может знать чего от нее могут попросить).

G>Ты уже написал порядка 10 постов про приведение типов, а еще НИКТО не понял что ты хочешь сказать. Может будешь учиться изъясняться понятнее?

Ты сам просил задачу, а не решение. Я описал в терминах заказчика. Вопрос понимания -- твоя проблема.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, hattab, Вы писали:

H>>Здравствуйте, Ведмедь, Вы писали:

H>>Улови основную мысль: человек бравирующий тем, что не знает устройства того на чем пишет/чем пользуется не способен написать качественного продукта. Учитывая тот факт, что .Net'а на десктопах что-то не видно, живет он в корпоративном секторе, где и трудятся сии умельцы крапающие свои пердульки.
G>Это еще требует доказаельства.
G>Кстати .NET на десктопах очень даже видно, но .NET позволяет делать не только десктопные прилодения, но и Web. А Web зачастую удобнее в использовании и проще в реализации.

Академический интерес: что именно видно на десктопах, может я упустил что?
Я лично видел три вещи: Paint.NET (посмотрел только из за того, что его постоянно приводят в пример в подобных СВ), гуй от драйверов для видеокарт ATI, nLite.
Из этих трёх программ мне полезна была только последняя. И таки да, для того, чтобы ей воспользоваться, пришлось разориться на 20 Мб траффика (.NET FW).

H>>Расширять функционал можно и без таких затрат. Мне для отрисовки гуя игровая видюха не нужна.
G>А кому нужна?

В WPF по рассказам наличествуют 3D-свистелки сомнительной нужности, не для них ли? Не наезда ради, хочу узнать.

Здравствуйте, gandjustas, Вы писали:

H>>Вот и чудно что не обязывает. Какой вариант будет использован средним разработчик чаще всего? Посыл ясен?
G>Средний разработчик на Java и .NET будет использовать конфиги.

Ну вот и пришли к тому, с чего начали. Мои поздравления.

G>А на делфи — не будет. В делфи для этого средств маловато.

Я не знаю о каких ты средствах... Давно уже храню конфиги в XML и проблем не имею

G>.NET и Java ты не знаешь.

Заметь, я этого никогда не утверждал. В отличии от "знатоков", якобы знающих Delphi

Здравствуйте, hattab, Вы писали:

G>>А на делфи — не будет. В делфи для этого средств маловато.

H>Я не знаю о каких ты средствах... Давно уже храню конфиги в XML и проблем не имею

У тебя, у бедняги, конфиги небось каждый день куда-то "пропадают". Вот и наболело...

Здравствуйте, gandjustas, Вы писали:

В>>>А у меня вопрос, а что-нибудь кроме паскаля за плечами есть? Или не читал, но осуждаю?

H>>До паскаля много чего было, после него только Ada в ознакомительном режиме. Под .Net собирался, но не собрался. Я удовлетворил твой интерес к моей скромной персоне?
G>Сейчас 2008 год, когда ты начал заниматься паскалем был 1995, в то время в России мало чего было. Сейчас это уже все устарело.

Какое мне дело до того, что устарело со времен 1995 года? Я на ObjectPascal (ну еще на асме, изредка и со справочником) пишу, и доволен жизнь.

В>>>Кстати хочу заметить, что ресурсы не потеряются, а будут освобождены только при следующей сборки мусора, что в условия ограниченного пула ресурсов может быть не приемлимо. Так что все равно со временем и файл и коннекция освободится... а в Паскале когда не освобожденный объект корректно освободится?

H>>Со временем... С каким? Сутки? Двое? В нативе оно конечно не освободится, но у натива и посыл другой: взял -- верни. Глубина проблемы ясна?
G>Никто не мешает писать в стиле взял — верни в управляемых средах (на самом деле так писать даже лучше). С одной поправкой: в управляемых средах память не является таким ресурсом.

Конечно не мешает, но кто так пишет?

G>Где тут глубина проблемы?

Глубина проблемы в том, что сперва ты расслабился, а потом тебе говорят расслабляться нельзя. Человеческий фактор. В нативе никогда расслабляться нельзя, и это вырабатывает четкое поведение: create -- free, new-dispose.

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, gandjustas, Вы писали:

H>Я показал запрос интерфейса. Но ты ранее сказал, что мое решение основанное на интерфейсах это следствие кривизны Delphi. Я от тебя видимо уже не дождусь примера на запрос объекта, ибо ты сказал, что и на объектах можно все реализовать. Причем, отдавать объекты посредством свойств нельзя, ибо противоречит условиям задачи (сущность не может знать чего от нее могут попросить).

Твое решение с ПОДСЧЕТОМ ССЫЛОК вызвано кривизной делфи. Потому что в делфи все интерфейсы — COM интерфейсы.
Интерфейсы, как средство абстракции, тут вообще не при чем.

Здравствуйте, hattab, Вы писали:
H>

H>...

H>HttpProxy := client As IHttpProxy;
H>SocksProxy := client As ISocksProxy;
H>HttpHeaders := client As IHttpHeaders;

H>

H>Как по твоему, в случае приведения типа к объекту, client должен являться наследником и THttpProxy и TSocksProxy и THttpHeaders? Теперь понятно о чем речь?

Т.е. Вы хотите агрегировать внутри THttpClient (если client является членом этого класса) классы THttpProxy, TSocksProxy и THttpHeaders?

interface IHttpProxy {...}
...
interface ISocksProxy {...}
...
interface IHttpHeaders {...}

...

//Это классы с готовой реализацией
class THttpProxy: IHttpProxy {...}
...
class TSocksProxy: ISocksProxy {...}
...
class THttpHeaders: IHttpHeaders {...}

/*
Теперь мы хотим в классе THttpClient унаследовать реализацию THttpProxy, TSocksProxy и THttpHeaders. Т.к. в C# множественного наследования нет, применяем агрегирование. При этом мы можем поступить несколькими способами
*/

class THttpClient
{
    private IHttpProxy httpProxy;
    private ISocksProxy socksProxy;
    private IHttpHeaders httpHeaders
}

/*
Способ 1 - Не скрываем агрегирование. Утверждаем, что THttpClient - это не прокси и не заголовки, а именно клиент, просто он оперирует проксями и заголовками. Запрещаем "as", зато даем доступ к членам:
*/
class THttpClient
{
    ...

    public IHttpProxy HttpProxy { get {return httpProxy;} }
    public ISocksProxy SocksProxy { get {return socksProxy;} }
    public IHttpHeaders HttpHeaders { get {return httpProxy;} }
}

//Т.е. вместо
client as IHttpProxy
//пишем
client.HttpProxy

/*
Способ 2 - Утверждаем, что THttpClient - это прокси и заголовки в одном флаконе. Реализуем все 3 интерфейса
*/
class THttpClient : IHttpProxy, ISocksProxy, IHttpHeader
{
    /*
    Далее в реализациях методов интерфейса обращаемся к соответствующим методам агрегированных членов
    */
}

//Здесь можно писать уже так, как Вы предлагали
client as IHttpProxy

/*
Теоретически можно было бы еще похимичить с операторами приведения типов, однако в C# они слишком сильно урезаны - решение получается кривое
*/

Здравствуйте, Сергей, Вы писали:

С>Академический интерес: что именно видно на десктопах, может я упустил что?
С>Я лично видел три вещи: Paint.NET (посмотрел только из за того, что его постоянно приводят в пример в подобных СВ), гуй от драйверов для видеокарт ATI, nLite.
С>Из этих трёх программ мне полезна была только последняя. И таки да, для того, чтобы ей воспользоваться, пришлось разориться на 20 Мб траффика (.NET FW).
А в гугле поискать? Я за несколько минут нашел несколько десятков шарованых/бесплатных программ.

С>В WPF по рассказам наличествуют 3D-свистелки сомнительной нужности, не для них ли? Не наезда ради, хочу узнать.
А кто-то заставляет использовать 3D в WPF?

Здравствуйте, hattab, Вы писали:

H>Я показал запрос интерфейса. Но ты ранее сказал, что мое решение основанное на интерфейсах это следствие кривизны Delphi. Я от тебя видимо уже не дождусь примера на запрос объекта, ибо ты сказал, что и на объектах можно все реализовать. Причем, отдавать объекты посредством свойств нельзя, ибо противоречит условиям задачи (сущность не может знать чего от нее могут попросить).

Ты утомил своим невежеством. RTFM про Factory Method pattern.

Здравствуйте, hattab, Вы писали:

H>Глубина проблемы в том, что сперва ты расслабился, а потом тебе говорят расслабляться нельзя. Человеческий фактор. В нативе никогда расслабляться нельзя, и это вырабатывает четкое поведение: create -- free, new-dispose.

Пиши еще.

Здравствуйте, hattab, Вы писали:

H>Какое мне дело до того, что устарело со времен 1995 года? Я на ObjectPascal (ну еще на асме, изредка и со справочником) пишу, и доволен жизнь.
Маладец.

В>>>>Кстати хочу заметить, что ресурсы не потеряются, а будут освобождены только при следующей сборки мусора, что в условия ограниченного пула ресурсов может быть не приемлимо. Так что все равно со временем и файл и коннекция освободится... а в Паскале когда не освобожденный объект корректно освободится?
H>>>Со временем... С каким? Сутки? Двое? В нативе оно конечно не освободится, но у натива и посыл другой: взял -- верни. Глубина проблемы ясна?
G>>Никто не мешает писать в стиле взял — верни в управляемых средах (на самом деле так писать даже лучше). С одной поправкой: в управляемых средах память не является таким ресурсом.
H>Конечно не мешает, но кто так пишет?
Я так пишу, все кто со мной работает — так пишет. Примеры из MSDN и книг этому очень способствуют.
На самом деле большенство так пишет.

G>>Где тут глубина проблемы?
H>Глубина проблемы в том, что сперва ты расслабился, а потом тебе говорят расслабляться нельзя. Человеческий фактор. В нативе никогда расслабляться нельзя, и это вырабатывает четкое поведение: create -- free, new-dispose.
Ну не говорил бы того, чего не знаешь.
На C# using написать совсем несложно. Он тебе Dispose и вызовет. Даже если где-то не напишешь — ничего критичного не произойдет в 99% случаев.

Здравствуйте, hattab, Вы писали:

H>Я не знаю о каких ты средствах... Давно уже храню конфиги в XML и проблем не имею

Ты же начал разговор что они пропадают. У тебя часто пропадают конфиги?

Здравствуйте, gandjustas, Вы писали:

H>>Улови основную мысль: человек бравирующий тем, что не знает устройства того на чем пишет/чем пользуется не способен написать качественного продукта. Учитывая тот факт, что .Net'а на десктопах что-то не видно, живет он в корпоративном секторе, где и трудятся сии умельцы крапающие свои пердульки.
G>Это еще требует доказаельства.

Вот как ты заговорил...

G>Кстати .NET на десктопах очень даже видно, но .NET позволяет делать не только десктопные прилодения, но и Web. А Web зачастую удобнее в использовании и проще в реализации.

Это еще требует доказательства

Marketing-bullshit.

H>>Расширять функционал можно и без таких затрат. Мне для отрисовки гуя игровая видюха не нужна.
G>А кому нужна?

WPF на средних/офисных компах тормозит (на моей буке, даже не WPF GUI WindowsLiveWriter тормозной). Погугли на предмет: WPF тормоза.

Здравствуйте, gandjustas, Вы писали:

H>>Я показал запрос интерфейса. Но ты ранее сказал, что мое решение основанное на интерфейсах это следствие кривизны Delphi. Я от тебя видимо уже не дождусь примера на запрос объекта, ибо ты сказал, что и на объектах можно все реализовать. Причем, отдавать объекты посредством свойств нельзя, ибо противоречит условиям задачи (сущность не может знать чего от нее могут попросить).

G>Твое решение с ПОДСЧЕТОМ ССЫЛОК вызвано кривизной делфи. Потому что в делфи все интерфейсы — COM интерфейсы.
G>Интерфейсы, как средство абстракции, тут вообще не при чем.

Ты и так уже доказал, что Delphi ты не знаешь. Не упорствуй.

Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, hattab, Вы писали:
H>>

H>>...

H>>HttpProxy := client As IHttpProxy;
H>>SocksProxy := client As ISocksProxy;
H>>HttpHeaders := client As IHttpHeaders;

H>>

H>>Как по твоему, в случае приведения типа к объекту, client должен являться наследником и THttpProxy и TSocksProxy и THttpHeaders? Теперь понятно о чем речь?

MC>Т.е. Вы хотите агрегировать внутри THttpClient (если client является членом этого класса) классы THttpProxy, TSocksProxy и THttpHeaders?
MC>

MC>interface IHttpProxy {...}
MC>...
MC>interface ISocksProxy {...}
MC>...
MC>interface IHttpHeaders {...}

MC>...

MC>//Это классы с готовой реализацией
MC>class THttpProxy: IHttpProxy {...}
MC>...
MC>class TSocksProxy: ISocksProxy {...}
MC>...
MC>class THttpHeaders: IHttpHeaders {...}

MC>/*
MC>Теперь мы хотим в классе THttpClient унаследовать реализацию THttpProxy, TSocksProxy и THttpHeaders. Т.к. в C# множественного наследования нет, применяем агрегирование. При этом мы можем поступить несколькими способами
MC>*/

MC>class THttpClient
MC>{
MC>    private IHttpProxy httpProxy;
MC>    private ISocksProxy socksProxy;
MC>    private IHttpHeaders httpHeaders
MC>}

MC>/*
MC>Способ 1 - Не скрываем агрегирование. Утверждаем, что THttpClient - это не прокси и не заголовки, а именно клиент, просто он оперирует проксями и заголовками. Запрещаем "as", зато даем доступ к членам:
MC>*/
MC>class THttpClient
MC>{
MC>    ...

MC>    public IHttpProxy HttpProxy { get {return httpProxy;} }
MC>    public ISocksProxy SocksProxy { get {return socksProxy;} }
MC>    public IHttpHeaders HttpHeaders { get {return httpProxy;} }
MC>}

MC>//Т.е. вместо
MC>client as IHttpProxy
MC>//пишем
MC>client.HttpProxy

MC>/*
MC>Способ 2 - Утверждаем, что THttpClient - это прокси и заголовки в одном флаконе. Реализуем все 3 интерфейса
MC>*/
MC>class THttpClient : IHttpProxy, ISocksProxy, IHttpHeader
MC>{
MC>    /*
MC>    Далее в реализациях методов интерфейса обращаемся к соответствующим методам агрегированных членов
MC>    */
MC>}

MC>//Здесь можно писать уже так, как Вы предлагали
MC>client as IHttpProxy

MC>/*
MC>Теоретически можно было бы еще похимичить с операторами приведения типов, однако в C# они слишком сильно урезаны - решение получается кривое
MC>*/
MC>

Ты зря старался

С интерфейсами и так все ясно. Я просил запрос классов.

Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, Сергей, Вы писали:

С>>Видимо, с пониманием смысла твоих сообщений туго не только у "дельфятников", поскольку к ним я не отношусь.
kuj>Ну-ну.

Ну вот, опять я тебя не понял. Что здесь означает этот оборот речи?

С>>Ты бы поменьше использовал подобные обороты речи и побольше бы писал бы о том, что имеешь ввиду — глядишь, и понимать лучше начнут.

kuj>Я всегда пишу "о том, что имею в виду".

Не сомневаюсь. Тем не менее, если бы ты меньше использовал те самые "обороты речи", было бы много лучше.

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	05.05.08 19:05
Оценка:

	От:	kuj
	Дата:	05.05.08 19:08
	Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	05.05.08 19:13
Оценка:

	От:	hattab
	Дата:	05.05.08 19:16
	Оценка:

	От:	Сергей
	Дата:	05.05.08 19:16
	Оценка: