В чём прикол class function?

← →
Ega23 © (2007-10-09 11:05) [0]

И в чём отличие от обычной function? Только то, что первая таки является методом, пусть и неявным?

← →
Kolan (2007-10-09 11:06) [1]

Прикол в том, что обращаешься к классу, имхо
TMyClass.DoSmth&#133

← →
Ega23 © (2007-10-09 11:08) [2]

Это к вопросу о реализацци паттерна синглтон

← →
clickmaker © (2007-10-09 11:08) [3]

в том, что не надо экземпляр создавать перед вызовом

← →
stone © (2007-10-09 11:09) [4]

Ты можешь обратиться к функции не создавая экземпляр класса.
Например, для проверки доступа к форме, можно создать функцию определяющую возможность доступа, и создавать форму только если эта функция вернула тру.

← →
Инс © (2007-10-09 11:12) [5]

В том, что class function может вызываться без создания экземпляра класса, для того, чтобы, скажем, вернуть некую информацию о классе вцелом, а не его экземпляре. В связи с этим ограничение - в class-function нельзя опрерировать полями/свойствами экземпляра. Вызывать class function можно (не создавая экземпляр) так:
<Имя класса>.<имя функции>

Пример:
TMyClass = class
public
class function GetVersion: String;
end;

....

class function TMyClass.GetVersion: String;
begin
Result:="1.01";
end;

Вызов:
Version:=TMyClass.GetVersion;

Классовые методы могут быть виртуальными.

← →
Ega23 © (2007-10-09 11:17) [6]

Не, это я всё прекрасно знаю и использую.
Просто вот подумалось, в чём отличие от обычной функции?

Ведь я вполне имею право так написать:

type TMyClass = class(...) public procedure DoSomething; class function Init : TMyClass; end; var MyClass : TMyClass; function TMyClass.Init : TMyClass; begin if Assigned(MyClass) then Result := MyClass else Result := TMyClass.Create; end;

А могу так:

type TMyClass = class(...) public procedure DoSomething; end; function GetMyClass : TMyClass; var MyClass : TMyClass; function GetMyClass : TMyClass; begin if Assigned(MyClass) then Result := MyClass else Result := TMyClass.Create; end;

Разницы в вызовах - практически никакой.
Тогда - зачем? Чисто удобства и эстетики ради?

← →
clickmaker © (2007-10-09 11:21) [7]

> [6] Ega23 © (09.10.07 11:17)

второй случай более процедурно-ориентированный, а не ООП. Нарушается понятие инкапсуляции

← →
stone © (2007-10-09 11:22) [8]

а если у тебя в юните нет объявления
var
MyClass : TMyClass;

что очень часто используется в MDI-приложениях?

← →
Суслик © (2007-10-09 11:22) [9]

а еще есть class function ... static
так тут в EAX даже ссылка на класс не передается - фактически вызов функции обычной, только под определенным namespace"ом.

← →
Ega23 © (2007-10-09 11:25) [10]

> stone © (09.10.07 11:22) [8]
>
> а если у тебя в юните нет объявления

Блин, да я не критикую. По мне так class function - гораздо удобнее.
Просто хотел поинетерсоваться, в чём всё-таки разница, кроме того, что class function - суть метод?

← →
Игорь Шевченко (2007-10-09 11:25) [11]

прикол в том, что плющит

← →
Инс © (2007-10-09 11:26) [12]

> Ega23 © (09.10.07 11:17) [6]

В подобном случае Борланд предпочитает второй вариант. Модуль Printers тому пример.

> Тогда - зачем?

зачем нужны классовые функции? Странный вопрос, через классовые функции например реализовано создание экземпляра. Ведь пока экземпляра не существует, нужно же как-то сославшись на класс правильно выделить для экземпляра память и вернуть указатель на нее.

← →
Суслик © (2007-10-09 11:32) [13]

стоит заметить, что дельфи, пожалуй единственный, из современных языков, в котором есть как чисто статические классовые методы, так и динамические (в общем случае виртуальные) классовые методы.

← →
DiamondShark © (2007-10-09 11:42) [14]

> Это к вопросу о реализацци паттерна синглтон

В паскале этот паттерн реализован на уровне языка.
Юнит -- это и есть синглтон.

← →
clickmaker © (2007-10-09 11:43) [15]

> в чём всё-таки разница, кроме того, что class function -
> суть метод?

ну вот фрагмент проекта

class function TActorForm.Execute(ActorID: integer; AMode: integer): TModalResult; var AccMode: integer; begin AccMode := GetAccessMode(CLASS_ID_ACTOR); if AccMode < 1 then begin MessageDialogFmt(E_ACCESS_DENIED, [GetClassTitle(CLASS_ID_ACTOR)], IDS_ACCESS_DENIED); Result := mrCancel; Exit; end; if AMode > AccMode then AMode := MODE_READ; with TActorForm.Create(Application) do begin try FMode := AMode; FActorID := ActorID; InitControls; Result := ShowModal; finally Free; end; end; end;

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

← →
sdubaruhnul (2007-10-09 11:47) [16]

>Ega23 © (09.10.07 11:17) [6]

>Разницы в вызовах - практически никакой.
Тогда - зачем? Чисто удобства и эстетики ради?

Может быть, ты ещё и глобальные переменные используешь?

← →
Инс © (2007-10-09 11:49) [17]

> Может быть, ты ещё и глобальные переменные используешь?

Все используют, Application, DecimalSeparator...

← →
Ega23 © (2007-10-09 11:51) [18]

> Может быть, ты ещё и глобальные переменные используешь?

Да. А что?

← →
oxffff © (2007-10-09 11:54) [19]

Самое интересное, что конструктор не является в чистом виде ни class и ни instance методом. В зависимости от dl он приобретает, то один, то другой вид.

← →
oxffff © (2007-10-09 12:01) [20]

> В чём прикол class function?

Классовые методы - это методы для работы с типом.
Фактически это методы для работы с интроспекцией

← →
Суслик © (2007-10-09 12:02) [21]

> интроспекцией

вау

← →
oxffff © (2007-10-09 12:09) [22]

> Суслик © (09.10.07 12:02) [21]
>
> > интроспекцией
>
> вау

+ см. [19].

Интроспекция

class function InitInstance(Instance: Pointer): TObject;
class function ClassName: ShortString;
class function ClassNameIs(const Name: string): Boolean;
class function ClassParent: TClass;
class function ClassInfo: Pointer;
class function InstanceSize: Longint;
class function InheritsFrom(AClass: TClass): Boolean;
class function MethodAddress(const Name: ShortString): Pointer;
class function MethodName(Address: Pointer): ShortString;
class function GetInterfaceEntry(const IID: TGUID): PInterfaceEntry;
class function GetInterfaceTable: PInterfaceTable;
class function NewInstance: TObject; virtual;

.NET System.Type + activators не напоминает

← →
DiamondShark © (2007-10-09 12:37) [23]

> .NET System.Type + activators не напоминает

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

← →
oxffff © (2007-10-09 12:58) [24]

> DiamondShark © (09.10.07 12:37) [23]
>
> > .NET System.Type + activators не напоминает
>
> В том-то и дело, что предоставлять информацию о типах и
> реализовывать операции по инстанцированию -- это задача
> операционной среды.
> Классовые функции не являются для этого необходимыми.

Посмотри реализацию _ClassCreate.

← →
DiamondShark © (2007-10-09 13:08) [25]

> Посмотри реализацию _ClassCreate.

Зачем?

← →
homm © (2007-10-09 13:11) [26]

> [0] Ega23 © (09.10.07 11:05)
> И в чём отличие от обычной function?
> [5] Инс © (09.10.07 11:12)
> В том, что class function может вызываться без создания экземпляра класса

Гениально. Видимо обычной function вызвать без создания экземпляра класса нельзя? :(

← →
Ega23 © (2007-10-09 13:13) [27]

> Гениально. Видимо обычной function вызвать без создания
> экземпляра класса нельзя? :(

Имелось ввиду TMyClass.Init
Ну, короче, кому надо - тот понял...

← →
homm © (2007-10-09 13:16) [28]

> [27] Ega23 © (09.10.07 13:13)

подожди, ты спрашивал отличия «class function» от «обычной function» или все-же от функции-члена?

← →
Kolan © (2007-10-09 13:17) [29]

> Юнит  это и есть синглтон.

Это коннечно не так по определению синглетона.

← →
Skyle © (2007-10-09 13:20) [30]

> Kolan © (09.10.07 13:17) [29]
> > Юнит —— это и есть синглтон.
> Это коннечно не так по определению синглетона.

А от какого определения отталкиваемся?

← →
oxffff © (2007-10-09 13:20) [31]

> DiamondShark © (09.10.07 13:08) [25]
>
> > Посмотри реализацию _ClassCreate.
>
> Зачем?

Для просветления.

>это задача операционной среды
что это? Где такое в Delphi?
В .NET такое по другому называется.

>В том-то и дело, что предоставлять информацию о типах и реализовывать >операции по инстанцированию

Классовые методы выполняют операции связанные с типом. В том числе предоставляют информацию о типе.

>Посмотри реализацию _ClassCreate.
>Зачем?

Чтобы узнать что для инстанцирования типа используется информация связанная с типом, которая предоставляется классовыми методами.

← →
Ins © (2007-10-09 13:25) [32]

> Ну, короче, кому надо - тот понял...

Действительно первый раз не правильно понял, было очень похоже, что под "обычным function" подразумевается обычный метод, а не классовый. Разница же между методом и обычной функцией (что автору и нужно было на самом деле) в том, что в метод неявно передается еще один параметр - self. Вот только для instance-методов и class-методов смысл этого параметра разный. В первом случае - указатель на экземпляр, во втором - указатель на информацию о типе класса.

← →
Ega23 © (2007-10-09 13:32) [33]

> Разница же между методом и обычной функцией (что автору
> и нужно было на самом деле) в том, что в метод неявно передается
> еще один параметр - self. Вот только для instance-методов
> и class-методов смысл этого параметра разный. В первом случае
> - указатель на экземпляр, во втором - указатель на информацию
> о типе класса.

Мне не это надо было. Разницу между обычной функией(процедурой) и методом я знаю. Про Self - мне тоже известно.
Просто интересно было: зачем Borland вводит сущность class function, если она реально ничем не отличается от простой функции, кроме как наличием этого самого Self?

Короче, просто любопытство.

← →
Ega23 © (2007-10-09 13:33) [34]

> Вот только для instance-методов и class-методов смысл этого
> параметра разный. В первом случае - указатель на экземпляр,
> во втором - указатель на информацию о типе класса.

О! Вот, собственно, это я и хотел услышать.
Теперь всё ясно. Вопрос снят.

← →
clickmaker © (2007-10-09 13:35) [35]

> зачем Borland вводит сущность class function

это понятие не борланд ввел.
В Си - static
В VB.Net - shared
Все дело в инкапсуляции. Если уж мы кодим в рамках ООП, так давайте там и оставаться. Иначе, чем это будет отличаться от процедурного программирования с использованием некоего АПИ?

← →
Kolan © (2007-10-09 13:35) [36]

> Вопрос снят.

Имхо Borland ввел её для поддержки ООП. Возможно даже, чтобы генерить паттерн синглетон одинаковый в Net и в Win32&#133

← →
oxffff © (2007-10-09 13:39) [37]

> Ega23 © (09.10.07 13:33) [34]
>
> > Вот только для instance-методов и class-методов смысл
> этого
> > параметра разный. В первом случае - указатель на экземпляр,
>
> > во втором - указатель на информацию о типе класса.
>
>
> О! Вот, собственно, это я и хотел услышать.
> Теперь всё ясно. Вопрос снят.

А ведь хотел я на help указать. :)

← →
Ins © (2007-10-09 13:40) [38]

> Просто интересно было: зачем Borland вводит сущность class
> function, если она реально ничем не отличается от простой
> функции, кроме как наличием этого самого Self?

Отличается. Возможностью делать такие методы виртуальными. Тут уже без Self никак не обойтись.

← →
Ega23 © (2007-10-09 13:41) [39]

> А ведь хотел я на help указать. :)

Да смотрел я, только видать не понял, или проглядел...

← →
Ins © (2007-10-09 13:41) [40]

> О! Вот, собственно, это я и хотел услышать.

Блин, ты уж определись, известно тебе про Self или не известно :)

← →
oxffff © (2007-10-09 13:50) [41]

> clickmaker © (09.10.07 13:35) [35]
>
> > зачем Borland вводит сущность class function
>
> это понятие не борланд ввел.
> В Си - static
> В VB.Net - shared
> Все дело в инкапсуляции. Если уж мы кодим в рамках ООП,
> так давайте там и оставаться. Иначе, чем это будет отличаться
> от процедурного программирования с использованием некоего
> АПИ?

В .Net вообще отказались от понятия классового метода.
Да и зачем вводить это понятие, если в рамках ООП можно все решить.
Просто ввели тип System.Type, который и выполняет аналогичные функции.

Зачем вводить понятия, если проще делегировать другому типу.
Это действительно разумнее с точки зрения ООП.
Хотя принципиально большой разницы нет.

← →
euru © (2007-10-09 15:00) [42]

> oxffff © (09.10.07 13:50) [41]
> Зачем вводить понятия, если проще делегировать другому типу.
> Это действительно разумнее с точки зрения ООП.
А чем проще и почему разумнее?

← →
DiamondShark © (2007-10-09 15:08) [43]

> Kolan © (09.10.07 13:17) [29]
> > Юнит —— это и есть синглтон.
>
> Это коннечно не так по определению синглетона.

Ок. Я даже не буду требовать определения синглетона. Скажу по-другому.
Если в языке поддерживается понятие модуля, то паттерн синглетон там нужен как зайцу стоп-сигнал.

← →
DiamondShark © (2007-10-09 15:10) [44]

> Зачем вводить понятия, если проще делегировать другому типу.

Действительно, зачем?
Хватило бы процедуры System.New

← →
Игорь Шевченко © (2007-10-09 15:10) [45]

> В .Net вообще отказались от понятия классового метода.

обозвав его словом static и смутив этим неокрепшие умы

← →
oxffff © (2007-10-09 15:11) [46]

> А чем проще и почему разумнее?

Единообразие.
+см. [19]

← →
oxffff © (2007-10-09 15:17) [47]

> Игорь Шевченко © (09.10.07 15:10) [45]
>
> > В .Net вообще отказались от понятия классового метода.
>
>
>
> обозвав его словом static и смутив этим неокрепшие умы

Для неокрепших умов. :)

Static member functions have external linkage. These functions do not have this pointers. As a result, the following restrictions apply to such functions:
They cannot access nonstatic class member data using the member-selection operators (. or –>).
They cannot be declared as virtual.
They cannot have the same name as a nonstatic function that has the same argument types.

← →
Игорь Шевченко © (2007-10-09 15:19) [48]

oxffff © (09.10.07 15:17) [47]

найди два отличия от классовых методов. (одно известно - виртуальными не могут быть)

← →
oxffff © (2007-10-09 15:21) [49]

> oxffff © (09.10.07 15:17) [47]
>
> > Игорь Шевченко © (09.10.07 15:10) [45]
> >
> > > В .Net вообще отказались от понятия классового метода.
>
> >
> >
> >
> > обозвав его словом static и смутив этим неокрепшие умы
>
>
> Для неокрепших умов. :)
>
>
> Static member functions have external linkage. These functions
> do not have this pointers. As a result, the following restrictions
> apply to such functions:
> They cannot access nonstatic class member data using the
> member-selection operators (. or –>).
> They cannot be declared as virtual.
> They cannot have the same name as a nonstatic function that
> has the same argument types.

Это для С++. Промахнулся. Одну секунду.

← →
euru © (2007-10-09 15:26) [50]

> oxffff © (09.10.07 15:11) [46]
> Единообразие.

А поподробнее можно? В чём единообразие?

← →
oxffff © (2007-10-09 15:31) [51]

> Игорь Шевченко © (09.10.07 15:19) [48]
> oxffff © (09.10.07 15:17) [47]
>
> найди два отличия от классовых методов. (одно известно -
> виртуальными не могут быть)

Для .net так же как в С++.

Но назначение и реализация классового (включая виртуальность) метода в delphi и static метода С++\.NET отличается.

← →
oxffff © (2007-10-09 15:38) [52]

> euru © (09.10.07 15:26) [50]
>
> > oxffff © (09.10.07 15:11) [46]
> > Единообразие.
>
> А поподробнее можно? В чём единообразие?

Все объекты и даже тип тоже является объектом (точнее объект wrapper).

← →
Черный Шаман (2007-10-09 15:40) [53]

> Ega23 © (09.10.07 11:25) [10]
>
>
> > stone © (09.10.07 11:22) [8]
> >
> > а если у тебя в юните нет объявления
>
>
> Блин, да я не критикую. По мне так class function - гораздо
> удобнее.
> Просто хотел поинетерсоваться, в чём всё-таки разница, кроме
> того, что class function - суть метод?

В Java есть static методы, также как static переменные, несто типа классовых констант. Удобно использовать для хранения настроек для всего класса или состояния класса. К примеру количества созданных объектов данного класса.

Полный функционал статических методов/полей класса(типизированные константы) реализован в Delphi начиная только с D2005.

Многие паттерны легко реализуются именно на статических методах.

← →
Игорь Шевченко © (2007-10-09 16:11) [54]

oxffff © (09.10.07 15:31) [51]

> Но назначение и реализация классового (включая виртуальность)
> метода в delphi и static метода С++\.NET отличается.

Реализация - безусловно отличается.
Но про отличия назначения давай подробнее аргументов...

← →
euru © (2007-10-09 16:33) [55]

> oxffff © (09.10.07 15:38) [52]

Т.е. вместо
s := TMyType.ClassName
проще
System.Type t = typeof(TMyType); s = t.Name;
?

А как поступать, если мне понадобится реализовать методы, возвращающие дополнительную информацию о типе?

← →
Alkid © (2007-10-09 17:13) [56]

Касательно синглтонов и классовых (статических) функций применительно к нему: фишка в том, что в кошерном синглтоне конструктор защищённый и не может быть вызван извне. Без классвойо (статической) функции это реализовать нельзя, ибо обычные функции могут иметь доступ только к публичным конструкторам.

← →
Ega23 © (2007-10-09 17:26) [57]

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

Лёха, я всё равно не понимаю, в чём принципиальная разница:

interface type TMyClass = class(...) public procedure DoSomething; class function Init : TMyClass; end; var MyClass : TMyClass; implementation function TMyClass.Init : TMyClass; begin if Assigned(MyClass) then Result := MyClass else Result := TMyClass.Create; end;

и

interface type TMyClass = class(...) public procedure DoSomething; end; function GetMyClass : TMyClass; var MyClass : TMyClass; imlementation function GetMyClass : TMyClass; begin if Assigned(MyClass) then Result := MyClass else Result := TMyClass.Create; end;

Даже если
var
MyClass : TMyClass;
в imlementation для каждого куска кода спрятать.

← →
clickmaker © (2007-10-09 17:31) [58]

> [57] Ega23 © (09.10.07 17:26)

точечка + Ctlr+пробел

← →
Alkid © (2007-10-09 17:32) [59]

Гм. Я тут вспомнил про то, что protected/private в рамках одного юнита не действуют.

Так что в принципиальной разницы нет.

← →
Ega23 © (2007-10-09 17:32) [60]

> точечка + Ctlr+пробел

Только это и больше ничто?

← →
clickmaker © (2007-10-09 17:33) [61]

> [60] Ega23 © (09.10.07 17:32)

пустячок, а приятно )

← →
Ega23 © (2007-10-09 17:34) [62]

> Я тут вспомнил про то, что protected/private в рамках одного
> юнита не действуют.

В смысле, наоборот?

← →
clickmaker © (2007-10-09 17:36) [63]

> [60] Ega23 © (09.10.07 17:32)

какая принципиальная разница

GetCurrentDirectory()
GetFileSize()
MakeFullPathName()

vs

Directory.GetCurrent()
File.GetSize()
Path.Combine()

?

← →
Ins © (2007-10-09 17:37) [64]

Принципиальная разница будет, если подразумеваются наследники TMyClass. В этом случае делаем конструктор виртуальном и первый вариант переделываем так:

function TMyClass.Init : TMyClass;
begin
if Assigned(MyClass) then Result := MyClass
else Result := Self.Create;
end;

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

← →
clickmaker © (2007-10-09 17:42) [65]

да, кстати, и это тоже

in the defining declaration of a class method, the identifier Self represents the class where the method is called (which could be a descendant of the class in which it is defined). If the method is called in the class C, then Self is of the type class of C. Thus you cannot use Self to access fields, properties, and normal (object) methods, but you can use it to call constructors and other class methods. (с) F1

← →
Ins © (2007-10-09 17:43) [66]

В общем, отвечая на первоначальный вопрос, "в чем прикол" - в том же, в чем и прикол любого метода по сравнению с обычной функцией/процедурой:
1. Техническая - В параметре Self
2. Идеологическая - в принципах ООП.

← →
euru © (2007-10-09 17:48) [67]

> Ega23 © (09.10.07 17:26) [57]

А если так:

interface type TMyClass = class(...) public class function Init: TMyClass; virtual; end; TMyClassEx = class(...) public class procedure DoSomething; class function Init: TMyClass; override; end; implementation var MyClass : TMyClass; function TMyClass.Init : TMyClass; begin if Assigned(MyClass) then Result := MyClass else Result := Self.Create; end; function TMyClassEx.Init: TMyClass; begin Result := inherited Init; DoSomething; end;

Правда, уже давно не работаю с Delphi, так что, может быть, что-нибудь напутал.

← →
euru © (2007-10-09 17:49) [68]

> Ins © (09.10.07 17:37) [64]
Значит, я что-то ещё помню. :)

← →
Ega23 © (2007-10-09 17:52) [69]

> Ins © (09.10.07 17:37) [64]

О!
Вот теперь ты мне точно всё разжевал. Сыпасибо!

← →
Ins © (2007-10-09 18:00) [70]

Я кстати по-моему погорячился насчет виртуальности конструктора. А вот Init нужно делать виртуальным, иначе Self может быть не тем, что нужно. Так что у euru © правильнее.

← →
Суслик © (2007-10-09 18:01) [71]

> 1. Техническая - В параметре Self

не забывай, что не всегда так - в современной дельфи есть с self"ом и без него.

← →
clickmaker © (2007-10-09 18:03) [72]

> в современной дельфи есть с self"ом и без него

а в военное время - так вообще с двумя :)

← →
euru © (2007-10-09 18:05) [73]

> clickmaker © (09.10.07 18:03) [72]
Т.е. Java изначально создавалась для применения в военное время? :)

← →
Суслик © (2007-10-09 18:11) [74]

> [72] clickmaker © (09.10.07 18:03)
> > в современной дельфи есть с self"ом и без него
> а в военное время - так вообще с двумя :)

в современном дельфи class proc совместимо с типом proc of object
а, class proc... static просто с типом proc.

правада фигово эту у них пока работает, но вроде обещали исправить.

← →
oxffff © (2007-10-09 18:36) [75]

> Игорь Шевченко © (09.10.07 16:11) [54]
> oxffff © (09.10.07 15:31) [51]
>
>
> > Но назначение и реализация классового (включая виртуальность)
>
> > метода в delphi и static метода С++\.NET отличается.
>
>
> Реализация - безусловно отличается.
> Но про отличия назначения давай подробнее аргументов...

static метод С++\.NET отличается от классового метода Delphi, но идентичен
class static методу Delphi.
Выше я говорил о классовых методах delphi и их назначении.

← →
oxffff © (2007-10-09 19:02) [76]

>
> euru © (09.10.07 16:33) [55]
>
> > oxffff © (09.10.07 15:38) [52]
>
> Т.е. вместо
> s := TMyType.ClassName
> проще
> System.Type t = typeof(TMyType);
> s = t.Name;
> ?
>
> А как поступать, если мне понадобится реализовать методы,
> возвращающие дополнительную информацию о типе?

Итак вернемся к назначению классовых методов delphi (non static) .
Их основное назначение обеспечить доступ к интроспекции.
Если внимательно посмотреть, то все классовые методы, за исключением одного невиртуальные.
Но им нужна была возможность(гибкость) (NewInstance) позволять типу "самому полиморфно инстанцироваться" и пришлось наделить полиморфизмом и метакласс. Именно поэтому и передается в классовый метод ссылка на метакласс. В то время не ввели еще понятие class var.
И поэтому с метаклассом нельзя было связывать поля (ну или почти нельзя ).

НО!!! Если внимательно посмотреть, то фактически метакласс ведет себя как обычный объект у него есть полиморфизм и наследование + сейчас уже добавили опеределять class var (инкапсуляция). За исключением требования существования в единственном экземпляре.

Что касаемо .NET. то такие финты там были не нужны и не предполагались.
Поскольку операции создания и удаления делегированы .NET Runtime .

← →
Kolan © (2007-10-09 19:17) [77]

> интроспекции.

А чейто такое? :)

← →
oxffff © (2007-10-09 19:25) [78]

> А чейто такое? :)

RTTI

← →
Kolan © (2007-10-09 19:27) [79]

Хм&#133 яндекс словари незнают&#133

← →
oxffff © (2007-10-09 19:34) [80]

Runtime Type Information (RTTI)

← →
vpbar (2007-10-09 21:15) [81]

>>clickmaker © (09.10.07 11:21) [7]
А как вам такое мнение.
http://www.softcraft.ru/coding/sm/sm02.shtml
И о том что есть инкапсуляция можно пофилософствовать.

>>[0]
Не совсем понял вопрос, но отвечу на оба.
Есть код:
TMyClass = class(Tobject) public FInt:Integer; class function Init: TMyClass; virtual; class procedure DoSomething; procedure DoSomethingNoClassMethod; class procedure CallInit; end; TMyClassEx = class(TMyClass) public class procedure DoSomething; class function Init: TMyClass; override; end; TMyClasses=class of TMyClass; ....................... { TMyClass } class procedure TMyClass.CallInit; begin ShowMessage("TMyClass.CallInit"); Init; // вызов виртуального метода класса. будет зависеть от self end; class procedure TMyClass.DoSomething; begin ShowMessage("TMyClass.DoSomething "+Self.ClassName); end; procedure TMyClass.DoSomethingNoClassMethod; begin ShowMessage("TMyClass.DoSomethingNoClassMethod "+Self.ClassName); end; class function TMyClass.Init: TMyClass; begin result:=Self.Create; ShowMessage("TMyClass.Init "+Self.ClassName); end; { TMyClassEx } class procedure TMyClassEx.DoSomething; begin ShowMessage("TMyClassEx.DoSomething "+ClassName); end; class function TMyClassEx.Init: TMyClass; begin ShowMessage("TMyClassEx.Init inherited Init"); Result := inherited Init; ShowMessage("TMyClassEx.Init "+Self.ClassName); end;
Чем отличается class method от процедуры. Только тем что метод класса может быть виртуальным.
Например

c:=TMyClass; // вызов class function init который возвращает экземпляр класса // c.Init; // вызов funciton init который возвращает экземпляр класса // отличий в логике почти нет // Init(c);

но следующий вариант с помощью процедур трудно реализовать
c:=TMyClass; c.CallInit; // в CallInit вызывается метод Init класса TMyClass c:=TMyClassEx; c.CallInit;// в CallInit вызывается метод Init класса TMyClassEx

Невиртуальные методы класса по сути не отличаются от процедуры которой передается указатель на информацию о типе класса (Self:class of TMyClass)

Метод класса отличается от обычного метода тем что в первом случае передается указатель на информацию о типе класса, а во втором на экземпляр класса.

← →
vpbar © (2007-10-09 21:34) [82]

>>Черный Шаман (09.10.07 15:40) [53]
Вроде в некоторой степени статические поля класса можно эммулировать так;
...... class function TMyClass.StaticField(value:integer=0;get:boolean=true): integer; {$WRITEABLECONST ON} const fStaticField:integer=0; {$WRITEABLECONST OFF} begin result:=fStaticField; if not get then fStaticField:=value; end; .... c.StaticField(10,false); // присваиваем 10 ShowMessage(inttostr(c.StaticField())); // получаем назад
Длинно, но я думаю потребность в таком редкая и это мелочи.

← →
euru © (2007-10-10 10:32) [83]

> oxffff © (09.10.07 19:02) [76]
Я правильно понял, что отказ от методов класса упрощает жизнь разработчикам языка программирования, а не использующим его программистам? Или всё-таки такой отказ даёт некие преимущества при программировании?

← →
oxffff © (2007-10-10 10:53) [84]

> euru © (10.10.07 10:32) [83]
>
> > oxffff © (09.10.07 19:02) [76]
> Я правильно понял, что отказ от методов класса упрощает
> жизнь разработчикам языка программирования, а не использующим
> его программистам? Или всё-таки такой отказ даёт некие преимущества
> при программировании?

Нет. Не правильно.
Я лишь говорил о связи классовых методов Delphi (non static) и .NET System.Type.
То что нельзя расширить определить полиморфные методы над самим типом .NET я не готов ответить плюс это или минус. Но это факт.
Но наличие такой возможности в Delphi - это безусловно плюс.
Думаю изначально разработчики Delphi ввели виртуальные классовые методы лишь для поддержки NewInstance.

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

Если необходимо связать полиморфную операцию с семейством типов, тогда конечно классовый метод это решение. Один пример это NewInstance.
Но честно говоря, какую еще информацию можно связать с семейством типов.
Привидите конкретный пример.

← →
Игорь Шевченко © (2007-10-10 10:58) [85]

oxffff © (09.10.07 18:36) [75]

> Выше я говорил о классовых методах delphi и их назначении.

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

← →
oxffff © (2007-10-10 11:15) [86]

> Игорь Шевченко © (10.10.07 10:58) [85]
> oxffff © (09.10.07 18:36) [75]
>
>
> > Выше я говорил о классовых методах delphi и их назначении.
>
>
>
> Давай ты уже расскажешь именно о различии в назначении или
> приведешь номер поста, где рассказл.

Delphi

Ordinary Class Methods - Self represents the class
Class Static Methods - no Self parameter at all.

.NET (ECMA-335)

Similarly, types can also declare methods that are associated with the type rather than with values of the type.
Such methods are static methods of the type. Since an invocation of a static method does not have an
associated value on which the static method operates, there is no this pointer available within a static method.

Поэтому

class static метод Delphi является аналогом static method .NET

Назначение Ordinary class method является доступ к интроспекции типа + полиморфные операции типа-определение способа размещения экземпляра типа.

C чем не согласны?

← →
oxffff © (2007-10-10 11:23) [87]

> То что нельзя расширить определить полиморфные методы над
> самим типом .NET я не готов ответить плюс это или минус.
> Но это факт.

Их конечно можно определить, но прямого способа их определения нет.

← →
Игорь Шевченко © (2007-10-10 12:00) [88]

oxffff © (10.10.07 11:15) [86]

> C чем не согласны?

С обоими (с)

Я согласен с тем, что методы класса и в .Net и в .Delphi предназначены для работы с метаданными объекта или как аналог обычных процедур/функций в языке, где кроме классов ничего нету (C#, Java, может быть, что-то еще).

← →
oxffff © (2007-10-10 12:14) [89]

> Игорь Шевченко © (10.10.07 12:00) [88]
> oxffff © (10.10.07 11:15) [86]
>
>
> > C чем не согласны?
>
>
> С обоими (с)
>
> Я согласен с тем, что методы класса и в .Net и в .Delphi
> предназначены для работы с метаданными объекта или как аналог
> обычных процедур/функций в языке, где кроме классов ничего
> нету (C#, Java, может быть, что-то еще).

Xм.
А как вы собираетесь работать с метаданными класса в .NET используя static метод класса, который фактически является regular proc c ограниченным scope до static class fields,methods.
Для этого и есть System.Type.

← →
isasa © (2007-10-10 15:55) [90]

oxffff © (10.10.07 12:14) [89]
А поюзать CustomAttribute членов, например ....

← →
euru © (2007-10-10 16:18) [91]

> oxffff © (10.10.07 10:53) [84]
> Привидите конкретный пример.

У меня нет конкретного примера. Собственно, как и утверждения, что

> Зачем вводить понятия, если проще делегировать другому типу.
> Это действительно разумнее с точки зрения ООП.

Я просто хочу знать, чем такой способ 1) проще и 2) разумнее не с точки зрения разработки языка программирования, а с точки зрения его применения.

← →
Игорь Шевченко © (2007-10-10 16:24) [92]

> А как вы собираетесь работать с метаданными класса в .NET
> используя static метод класса

Точно также, как Delphi, в С++ плюс isasa © (10.10.07 15:55) [90]
Если есть метод, который не зависит от конкретного экземпляра, то я не вижу причины не сделать его class function или class procedure. При этом вызывающая сторона не подозревает о том, какой это метод, работая с экземпляром.

← →
euru © (2007-10-10 16:32) [93]

> Игорь Шевченко © (10.10.07 16:24) [92]
В С# нельзя обратиться к статическому методу класса через экземпляр этого класса.

← →
Игорь Шевченко © (2007-10-10 16:39) [94]

euru © (10.10.07 16:32) [93

Через тип можно обратиться, особой разницы не вижу.

← →
oxffff © (2007-10-10 16:43) [95]

Игорь Шевченко © (10.10.07 16:24) [92]
isasa © (10.10.07 15:55) [90]
Игорь Шевченко © (10.10.07 16:39) [94]

MSDN
A static method, field, property, or event is callable on a class even when no instance of the class has been created. If any instances of the class are created, they cannot be used to access the static member. Only one copy of static fields and events exists, and static methods and properties can only access static fields and static events

← →
oxffff © (2007-10-10 16:44) [96]

> Игорь Шевченко © (10.10.07 16:39) [94]
> euru © (10.10.07 16:32) [93
>
> Через тип можно обратиться, особой разницы не вижу.

Да в том, что принципиально разница есть. см [86]

← →
euru © (2007-10-10 16:45) [97]

> Игорь Шевченко © (10.10.07 16:39) [94]
Ну, тогда вызывающая сторона должна явно знать, что вызываемый метод статический и что этот метод привязан к конкретному классу.

← →
Игорь Шевченко © (2007-10-10 16:47) [98]

oxffff © (10.10.07 16:43) [95]

> static methods and properties can only access static fields
> and static events

У бабочек (в смысле, в Delphi) то же самое. А в версиях до 2005 и статических свойств и полей не было.

Я, если честно, не понимаю, что ты мне хочешь доказать.

← →
Суслик © (2007-10-10 16:52) [99]

я вот тоже не понимаю о чем спор.

будучи заинтересованным читателей попрошу oxffff описать предмет спора (я тоже хочу поучаствовать :) ).

← →
clickmaker © (2007-10-10 16:54) [100]

> я вот тоже не понимаю о чем спор.

"я дерусь... потому что я дерусь!"
(c) Портос
:)

← →
oxffff © (2007-10-10 16:55) [101]

> Игорь Шевченко © (10.10.07 16:47) [98]
> oxffff © (10.10.07 16:43) [95]
>
>
> > static methods and properties can only access static fields
>
> > and static events
>
>
> У бабочек (в смысле, в Delphi) то же самое. А в версиях
> до 2005 и статических свойств и полей не было.
>
> Я, если честно, не понимаю, что ты мне хочешь доказать.

Игорь Шевченко © (09.10.07 15:10) [45].

Я лишь стараюсь указать на различие между классовыми методами Delphi и static методами С++ и .NET
И на их идентичность (С++ и .NET) со статическими классовыми методами Delphi.

← →
oxffff © (2007-10-10 16:56) [102]

> clickmaker © (10.10.07 16:54) [100]
>
> > я вот тоже не понимаю о чем спор.
>
> "я дерусь... потому что я дерусь!"
> (c) Портос
> :)

Неа. Я сейчас перерабатываю свой трехмерный движок.

← →
Суслик © (2007-10-10 16:58) [103]

> Я лишь стараюсь указать на различие между классовыми методами
> Delphi и static методами С++ и .NET
> И на их идентичность (С++ и .NET) со статическими классовыми
> методами Delphi.

я думаю, что это всем и так известно. нет?

← →
euru © (2007-10-10 17:01) [104]

> Игорь Шевченко © (10.10.07 16:47) [98]

Но в Delphi, насколько я помню, можно вызывать методы класса через экземпляры класса.

← →
oxffff © (2007-10-10 17:03) [105]

> euru © (10.10.07 17:01) [104]
>
> > Игорь Шевченко © (10.10.07 16:47) [98]
>
> Но в Delphi, насколько я помню, можно вызывать методы класса
> через экземпляры класса.

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

← →
euru © (2007-10-10 17:03) [106]

> oxffff © (10.10.07 16:56) [102]

А что по поводу euru © (10.10.07 16:18) [91]?

← →
oxffff © (2007-10-10 17:06) [107]

> euru © (10.10.07 16:18) [91]
>
> > oxffff © (10.10.07 10:53) [84]
> > Привидите конкретный пример.
>
> У меня нет конкретного примера. Собственно, как и утверждения,
> что
>
>
> > Зачем вводить понятия, если проще делегировать другому
> типу.
> > Это действительно разумнее с точки зрения ООП.
>
>
> Я просто хочу знать, чем такой способ 1) проще и 2) разумнее
> не с точки зрения разработки языка программирования, а с
> точки зрения его применения.

Думаю с точки зрения применения никакой разницы нет.

← →
oxffff © (2007-10-10 17:10) [108]

> Думаю с точки зрения применения никакой разницы нет.

Хотя есть одно. в .NET языках (хотя бы С#) нет прямого способа определить виртульный метод для наследника System.Type. Хотя технически ничего не мешает. Видимо посчитали, что это не нужно.

← →
euru © (2007-10-10 17:10) [109]

> oxffff © (10.10.07 17:03) [105]
Из языков я предпочитаю ABAP :)

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

← →
oxffff © (2007-10-10 17:16) [110]

> euru © (10.10.07 17:10) [109]
>
> > oxffff © (10.10.07 17:03) [105]
> Из языков я предпочитаю ABAP :)

Да вы что. :)
И я тоже на нем программирую.

← →
euru © (2007-10-10 17:19) [111]

> oxffff © (10.10.07 17:06) [107]
> Думаю с точки зрения применения никакой разницы нет.

Т.е. знание о возможности получения информации о классе от самого класса равносильно знанию о том, что для получения информации о классе необходимо знать о существовании другого класса, предоставляющего эту информацию, а также о наличии специального оператора для получения этого другого класса.

← →
vpbar © (2007-10-10 17:23) [112]

>>euru © (10.10.07 17:19) [111]
Даа. Заработался. Три раза перечитывал пока понял что написано :)
Не равносильно. Но с точки зрения применения никакой разницы нет

← →
oxffff © (2007-10-10 17:35) [113]

> euru © (10.10.07 17:19) [111]
>
> > oxffff © (10.10.07 17:06) [107]
> > Думаю с точки зрения применения никакой разницы нет.
>
> Т.е. знание о возможности получения информации о классе
> от самого класса равносильно знанию о том, что для получения
> информации о классе необходимо знать о существовании другого
> класса, предоставляющего эту информацию, а также о наличии
> специального оператора для получения этого другого класса.
>

Дело вкуса. Ведь по большому счету и там и там делегирование.

Delphi

mov ecx,[eax], где eax - Object type

C#
objectRef.getType() если .NET Runtime сделает inline, то вообще замечательно.

← →
euru © (2007-10-10 17:42) [114]

> vpbar © (10.10.07 17:23) [112]
> Не равносильно. Но с точки зрения применения никакой разницы
> нет

До тех пор пока я не захочу предоставлять какую-либо дополнительную информацию о классе либо существующую информацию, но через другой класс.

← →
oxffff © (2007-10-10 17:43) [115]

> Object type

TObject type

>C#
>objectRef.getType() если .NET Runtime сделает inline, то вообще >замечательно.

Inline не пахнет. Так что с точки зрения скорости медленнее.

← →
Игорь Шевченко © (2007-10-10 17:46) [116]

oxffff © (10.10.07 16:55) [101]

> Я лишь стараюсь указать на различие между классовыми методами
> Delphi и static методами С++ и .NET
> И на их идентичность (С++ и .NET) со статическими классовыми
> методами Delphi.

Замечательно. С тем, что есть различия реализации, я целиком и полностью согласен.

Но, насколько я помню, наша дискуссия завязалась из-за разного подхода к различию назначения.
Я повторюсь - если не учитывать различия реализации и конкретные особенности, вытекающие из этих различий, то в чем разница-то ? :)

← →
oxffff © (2007-10-10 17:52) [117]

> то в чем разница-то ? :)

См. euru [97].

Ну или еще проще, то также как между указателями на метод С++ и указатель на метод в Delphi.

С++ мы должны явно указать тип.
+ никакого позднего связывания.

← →
Игорь Шевченко © (2007-10-10 18:02) [118]

oxffff © (10.10.07 17:52) [117]

> См. euru [97].

См. Игорь Шевченко © (10.10.07 17:46) [116]

Не надо отталкиваться от различий в реализации.

← →
euru © (2007-10-10 18:10) [119]

> Игорь Шевченко © (10.10.07 18:02) [118]
Различия реализации могут в общем случае привести в различиях назначения.

← →
oxffff © (2007-10-10 19:14) [120]

>
> Игорь Шевченко © (10.10.07 18:02) [118]
> oxffff © (10.10.07 17:52) [117]
>
>
> > См. euru [97].
>
>
> См. Игорь Шевченко © (10.10.07 17:46) [116]
>
> Не надо отталкиваться от различий в реализации.

Назначение разное.

procedure abc(a:Tclass);
begin
showmessage(inttostr(a.InstanceSize));
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
abc(TButton);
abc(Tobject);
end;

В случае class static метода. Вы делать так.

class procedure Myclass1.abc;static
begin
showmessage(inttostr(Myclass1.InstanceSize));
end;

class procedure Myclass2.abc;static
begin
showmessage(inttostr(Myclass2.InstanceSize));
end;

class procedure Myclass3.abc;static
begin
showmessage(inttostr(Myclass3.InstanceSize));
end;

← →
oxffff © (2007-10-10 19:21) [121]

Я думаю не совсем корректно они дали название как class var, так сlass static proc. Дали бы просто Static название и путаницы было бы меньше.
Так как отношения к классу как таковому не имеют, а только имеет отношение к класс Scope.

class var - некорректное название поскольку подразумевает, что данный метакласс обладает переменной, но не разделяет ее с дочерними классами.
А class var разделяет дочерними классами.

Более корректное определение просто static var, static proc.

Ну не смертельно будем знать, что это значит.

← →
oxffff © (2007-10-11 09:39) [122]

← →
Игорь Шевченко © (2007-10-11 09:51) [123]

euru © (10.10.07 18:10) [119]

> Различия реализации могут в общем случае привести в различиях
> назначения.

Не надо про общие случаи. Давай про конкретный случай - классовые методы.

oxffff © (10.10.07 19:14) [120]

> Назначение разное.

Дорогой друг, назначение описывается словами, а не кодом.

Это общая беда или я чего-то не понимаю ? От того, что в ассемблере VAX операция присваивания записывается mov source,destination, а в ассемблере x86 mov destination,source у команды mov тоже разное назначение ?

Абстрагируйтесь, плиз, от реализации

← →
oxffff © (2007-10-11 10:10) [124]

Классовый метод Delphi - это классовый метод Delphi.
Его назначение работа с метаклассом.
Классовый метод работает только с метаклассом
В котором есть поля (Эти поля по отрицательному смещению от VMT).
Нормальными средствами дополнить эти поля мы не можем.

Статичный метод в С++,.NET является статичным, но не классовым.
Связан он с классом и дочерними классами только областью видимости.
Так же как и static поля, которые связаны с классом только областью видимости. Как вы указали выше, это обычные процедуры и глобальные переменные с ограниченной областью видимости.
Поэтому все статичные методы и статичные поля имеют отношение к дереву или лесу классов. Но они не связаны с каким то определенным классом.

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

Аналогом в Delphi статичным методов и статичных полей является class var и class static proc.
Хотя как я указал выше - это название может сбить с толку.

← →
euru © (2007-10-11 11:10) [125]

> Игорь Шевченко © (11.10.07 09:51) [123]
> Не надо про общие случаи. Давай про конкретный случай -
> классовые методы
На уровне гипотезы. Но пока опровержения не встречались.

Множество статических методов является подмножеством классовых методов. Т.е. любой статический метод можно записать в виде классового метода. Обратное возможно только в частных случаях.

Если эта гипотеза верна, то введение в Delphi понятие статического метода - лишнее усложнение языка.

← →
Игорь Шевченко © (2007-10-11 12:13) [126]

> В котором есть поля (Эти поля по отрицательному смещению
> от VMT).
> Нормальными средствами дополнить эти поля мы не можем.

Ты что, скрипач, дальтоник ? Зеленый от оранжевого отличить не можешь ?
Какая мне разница, что такое VMT и отрицательные смещения ?

Классовый метод - это метод, не зависящий от конкретного экземпляра.
И не более того. Может обращаться данным, не зависящим от экземпляра, например, к метаданным (if any), может вызывать другие классовые методы, может возвращать константы.

← →
oxffff © (2007-10-11 12:21) [127]

Если рассмотреть метакласс как обычный объект, то статический метод будет процедурой или функций объявленной в class namespace, так же как и class var. :)

Но вот 5 квалификаторов видимости запутывают эту картину еще сильней.

← →
oxffff © (2007-10-11 12:27) [128]

> Игорь Шевченко © (11.10.07 12:13) [126]
>
> > В котором есть поля (Эти поля по отрицательному смещению
>
> > от VMT).
> > Нормальными средствами дополнить эти поля мы не можем.
>
>
>
> Ты что, скрипач, дальтоник ? Зеленый от оранжевого отличить
> не можешь ?
> Какая мне разница, что такое VMT и отрицательные смещения
> ?
>
> Классовый метод - это метод, не зависящий от конкретного
> экземпляра.
> И не более того. Может обращаться данным, не зависящим от
> экземпляра, например, к метаданным (if any), может вызывать
> другие классовые методы, может возвращать константы.

Вы явно не хотите даже прочитать. Вам 156 раз сказали.
Что не может статический метод обратиться к метаданным, не указав явно тип. А если делать так,то вообще смысл этих статических методов в чем?
Если тоже самое можно сделать с помощью обычных процедур.

При всем уважение к вам.
Извольте почитать мат часть.

← →
vpbar © (2007-10-11 12:30) [129]

Нда, видимо верно :)
"Для программистов на C++ или Delphi термин метакласс вызывает некоторые сложности в понимании. В C++ и Delphi самым базовым объектом является класс. Методы и данные класса являются постоянными (static) членами класса. В случае SOM ситуация иная. В упрощенном понимании, классы являются экземплярами метаклассов, а объекты являются экземплярами классов. Метакласс содержит все функции и данные, относящиеся к классу. Говоря иначе, метакласс может содержат данные и методы, которые в C++ и Delphi явно или косвенно объявлены статическими, к которым относятся, например, конструкторы." (с)http://ru.ecomstation.ru/showarticle.php?id=144

← →
Ins © (2007-10-11 12:31) [130]

> А если делать так,то вообще смысл этих статических методов
> в чем?

В области видимости смысл и только. Тоже считаю, что у дельфийских классовых методов смысл несколько иной.

← →
oxffff © (2007-10-11 12:35) [131]

> Ins © (11.10.07 12:31) [130]
>
> > А если делать так,то вообще смысл этих статических методов
>
> > в чем?
>
> В области видимости смысл и только. Тоже считаю, что у дельфийских
> классовых методов смысл несколько иной.

oxffff © (11.10.07 12:21) [127].
А как быть с private, protected, public Да еще и +strict?

← →
reonid © (2007-10-11 12:35) [132]

>Ins © (11.10.07 12:31) [130]

Всё дело в виртуальности. И только.
Классовый метод в дельфях может быть виртуален,
а статический метод класса в С++, из которого растут
ноги у статических классовых методов дотнета - не может.

Естественно, что у виртуальных функций смысл несколько иной,
чем у невиртуальных.

← →
Игорь Шевченко © (2007-10-11 12:38) [133]

> Что не может статический метод обратиться к метаданным,
> не указав явно тип

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

← →
oxffff © (2007-10-11 12:40) [134]

> vpbar © (11.10.07 12:30) [129]
> Нда, видимо верно :)
> "Для программистов на C++ или Delphi термин метакласс вызывает
> некоторые сложности в понимании. В C++ и Delphi самым базовым
> объектом является класс. Методы и данные класса являются
> постоянными (static) членами класса. В случае SOM ситуация
> иная. В упрощенном понимании, классы являются экземплярами
> метаклассов, а объекты являются экземплярами классов. Метакласс
> содержит все функции и данные, относящиеся к классу. Говоря
> иначе, метакласс может содержат данные и методы, которые
> в C++ и Delphi явно или косвенно объявлены статическими,
> к которым относятся, например, конструкторы." (с)http://ru.
> ecomstation.ru/showarticle.php?id=144

Только вот в С++ нет понятия метакласс.
Есть понятие родовой класс, хотя Гради Буч и использует понятие метакласс.
Но это не метакласс в понимании Delphi.

← →
vpbar © (2007-10-11 12:41) [135]

>>oxffff © (11.10.07 12:40) [134]
>>Только вот в С++ нет понятия метакласс.
Да?
>>Но это не метакласс в понимании Delphi.
Это точнее. В Delphi тоже нет метаклассов..... в понимани Smalltalk-а

← →
Ins © (2007-10-11 12:42) [136]

> oxffff © (11.10.07 12:35) [131]

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

← →
Ins © (2007-10-11 12:47) [137]

> Еще раз - классовый метод может работать с данными, не зависящими
> от конкретного экземпляра.

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

> Классовый метод в дельфях может быть виртуален

Естественно и именно потому, что он знает о классе, которому принадлежит. И в этом его отличие от статического метода.

← →
oxffff © (2007-10-11 12:48) [138]

> reonid © (11.10.07 12:35) [132]
> >Ins © (11.10.07 12:31) [130]
>
> Всё дело в виртуальности. И только.
> Классовый метод в дельфях может быть виртуален,
> а статический метод класса в С++, из которого растут
> ноги у статических классовых методов дотнета - не может.
>
>
> Естественно, что у виртуальных функций смысл несколько иной,
>
> чем у невиртуальных.

Классовый метод работает с абстракцией метакласса.
Хейлсберг и его три другие кореша реализовал в .NET тоже самое только выделив это в отдельный объект экземпляр System.Type.
Поэтому методы System.Type являются аналогами классовых методов
Delphi. Принципиально ничего не мешает им ввести в .NET способ
определить дополнительные методы для описателя типа - экземпляра System.Type. Но это не введено в язык. И видимо и не нужно.
Также как и их виртуальность.
Ведь виртуальный классовый метод, нужен был только для целей NewInstance, для полиморфного определения поведения метода разщения экземпляра типа. Фактически это возможность в большинстве случаев не используют. Но можно значительно ускорить создание объектов не постоянно обращаесть менеджеру кучи, А например к пулу объектов.
А поскольку способ размещения объектов .NET в управляемой куче, то виртульность классового метода не нужна

← →
Ins © (2007-10-11 12:48) [139]

> reonid © (11.10.07 12:35) [132]

Да к тому же я в [38] это говорил. ;-)

← →
Ins © (2007-10-11 12:51) [140]

> Ведь виртуальный классовый метод, нужен был только для целей
> NewInstance

А откуда такие сведения? Лично я возможность делать классовые методы виртуальными использую, значит это сделали и для меня в т.ч. :)

> Ведь виртуальный классовый метод, нужен был только для целей
> NewInstance, для полиморфного определения поведения метода
> разщения экземпляра типа

Ерунда, уж извини. Я, например, довольно активно использую виртуальные классовые методы на Delphi, когда мне надо обратиться к свойствам конкретного класса (не объекта), заранее неизвестного, но являющегося наследником известного предка.

> vpbar © (11.10.07 12:41) [135]
> >>oxffff © (11.10.07 12:40) [134]
> >>Только вот в С++ нет понятия метакласс.
> Да?
> >>Но это не метакласс в понимании Delphi.
> Это точнее. В Delphi тоже нет метаклассов..... в понимани
> Smalltalk-а

Еще раз.
Русский перевод одинаков. А смысл разный.
Он (Буч) его называет параметризованный класс, метакласс, родовой класс.
Но это не метакласс в понимании Delphi.

у меня вообще весь мой object-persistant-framework устроен на виртуальных классовых методах.

> Игорь Шевченко © (11.10.07 12:38) [133]
> Еще раз - классовый метод может работать с данными, не зависящими от конкретного экземпляра.

Классовый метод зависит от класса, от имени которого его вызывают.
Статический метод не зависит от класса, он привязан к вполне определённому классу.

>>oxffff © (11.10.07 12:52) [142]
Дык. Еще раз я не спорю что эта штука в С++ не метакласс в понимании Delphi.
Я не совсем понимаю что такое метакласс вообще. А в делфи вообще где сказано про метаклассы?

Спор вообще о чем? О том, что классовый метод в понимании Delphi и static-метод в понимании .NET - это не одно и то же? Я считаю, что не одно и то же. Кто еще так считает?

> Игорь Шевченко © (11.10.07 12:52) [141]
>
> > Ведь виртуальный классовый метод, нужен был только для
> целей
> > NewInstance, для полиморфного определения поведения метода
>
> > разщения экземпляра типа
>
>
> Ерунда, уж извини. Я, например, довольно активно использую
> виртуальные классовые методы на Delphi, когда мне надо обратиться
> к свойствам конкретного класса (не объекта), заранее неизвестного,
> но являющегося наследником известного предка.

нет, не ерунда.
Активно он используется именно для этих целей (для NewInstance).
И придумали его для этих целей. аля перегрузка оператора new(C++)

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

> Кто еще так считает?

Я

Ибо в дельфи теперь есть оба варианта, и static и не-static.

> Суслик © (11.10.07 12:56) [143]
> у меня вообще весь мой object-persistant-framework устроен
> на виртуальных классовых методах.

Я тоже использую его. Но только по причине см [147]

> Ибо в дельфи теперь есть оба варианта, и static и не-static.

Тоже логично, но у меня аргументация такая: классовый метод, как следует из его названия, знает к какому классу он относится и позволяет оперировать данными самого класса, к которому он относится, а не его экземпляра. Это и есть его прямое предназначение. Статический метод .NET этого не позволяет, без явного указания на класс. Поэтому назвать его классовым методом с этой точки зрения нельзя.

> Я тоже использую его. Но только по причине см [147]

Я тоже использую его. Но только по причине см [148]

> Поэтому методы System.Type являются аналогами классовых методов

Я с дотнетом не работаю, так что могу ошибаться.
Насколько я понимаю, методы System.Type - это всего лишь методы
объекта, имеющего тип System.Type. И они могут быть
даже невиртуальными, ведь наследников у System.Type нет.
Или я ошибаюсь?

В дельфях, например, обратиться к пользовательским
виртуальным классовым методам можно только через
переменную, имеющую тип
TXXXClass = class of TXXX. Есть ли аналог чего-нибудь
подобного в дотнет?

> oxffff © (11.10.07 13:02) [148]
>
> > Игорь Шевченко © (11.10.07 12:52) [141]
> >
> > > Ведь виртуальный классовый метод, нужен был только для
>
> > целей
> > > NewInstance, для полиморфного определения поведения
> метода
> >
> > > разщения экземпляра типа
> >
> >
> > Ерунда, уж извини. Я, например, довольно активно использую
>
> > виртуальные классовые методы на Delphi, когда мне надо
> обратиться
> > к свойствам конкретного класса (не объекта), заранее неизвестного,
>
> > но являющегося наследником известного предка.
>
>
> нет, не ерунда.
> Активно он используется именно для этих целей (для NewInstance).
>
> И придумали его для этих целей. аля перегрузка оператора
> new(C++)
>
> А то, что не было средств для расширения полей метакласса,
> поэтому вам и приходиться полагаться на виртуальный классовый
> метод.
> А если бы были, то вам хватило бы и невиртуального метода.
>

Их прочем и сейчас нет.
class var - restricted global var class scope

Кстати мы действительно отошли от темы.

см. Ins © (11.10.07 12:59) [147]

> Суслик © (11.10.07 13:03) [149]

Считаете ли вы, что тут дело не только в аспектах реализации, но есть и идеологические различия?

> reonid © (11.10.07 13:10) [154]
> > Поэтому методы System.Type являются аналогами классовых
> методов
>
> Я с дотнетом не работаю, так что могу ошибаться.
> Насколько я понимаю, методы System.Type - это всего лишь
> методы
> объекта, имеющего тип System.Type. И они могут быть
> даже невиртуальными, ведь наследников у System.Type нет.
>
> Или я ошибаюсь?
>
> В дельфях, например, обратиться к пользовательским
> виртуальным классовым методам можно только через
> переменную, имеющую тип
> TXXXClass = class of TXXX. Есть ли аналог чего-нибудь
> подобного в дотнет?

Я тоже вообще практически с ним не работаю, только ecma читаю

System.Type

Represents type declarations: class types, interface types, array types, value types, enumeration types, type parameters, generic type definitions, and open or closed constructed generic types.

Фактически это средство доступа к метаданным.
Это обобщенное средство того, что дает в Delphi Typeinfo и метакласс

Судя по всему на каждый тип в создаетеся по одному экземпляру System.Type.

>В дельфях, например, обратиться к пользовательским
>виртуальным классовым методам можно только через
>переменную, имеющую тип
>TXXXClass = class of TXXX. Есть ли аналог чего-нибудь
>подобного в дотнет?

Языковых средств не предусмотрено для введения виртуальных функций System.Type.

← →
etc (2007-10-11 13:20) [158]

> ведь наследников у System.Type нет.
> Или я ошибаюсь?

ошибаетесь, он абстракный, да и наследовать от него незапрещено

> etc (11.10.07 13:20) [158]
Спасибо. Буду знать.
Интересно, имеет смысл наследник этого типа, написанный пользователем?
Иначе сей факт это всего лишь деталь реализации...

> oxffff © (11.10.07 13:19) [157]

Тогда эта фраза
>> Поэтому методы System.Type являются аналогами классовых методов
имеет смысл: это разные вещи, но и те, и другие применяются
для доступа к метаданным. Больше между ними ничего общего нет.

Но область применения дельфийских классовых методов,
вообще говоря, метаданными не ограничивается.
А как же пользовательские виртуальные классовые методы?

> [156] Ins © (11.10.07 13:19)
> > Суслик © (11.10.07 13:03) [149]
> Считаете ли вы, что тут дело не только в аспектах реализации,
> но есть и идеологические различия?

Если честно, то я считаю, что текущее состояние языка object-delphi является вынужденным. Безусловно некая идеология есть здесь. Но Дельфи всегда придерживался принципа

что-то follows implemntation.

Например, documentation follows implementation, theory follows implementation and so on.

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

ЗЫ Не сам придумал, читал о такой позиции в группах еще тогда борландовых.

:)
спор переходит в плоскость:
"А нужно ли ставить автомобиль на яму, если в нем имеется капот?"

> etc (11.10.07 13:20) [158]
>
> > ведь наследников у System.Type нет.
> > Или я ошибаюсь?
>
> ошибаетесь, он абстракный, да и наследовать от него незапрещено

Странно пример это не подтверждает.

public Form1()
{
String A="abc";
String C = "asdasd";
Int32 B=0;

if (A.GetType() == C.GetType())
{
B = B + 1;
}
if (A.GetType() == B.GetType())
{
B = B + 2;
}
if (A.GetType().GetType()==B.GetType().GetType())
{
B=B+4;
}
InitializeComponent();
}

первых if - TRUE (типы совпадают)
второй if - FALSE (типы не совпадают)
третий if - TRUE (тип для типов совпадают)

Согласно третьему вы не правы.
Тип описатель для типов описателей для типов String и Int32 идентичен

Да и где написано, что он абстрактный?

:) Дельфи нет под рукой, но думаю там аналогично ...
C# [SerializableAttribute] [ComVisibleAttribute(true)] [ClassInterfaceAttribute(ClassInterfaceType.None)] public abstract class Type : MemberInfo, _Type, IReflect Type is the root of the System.Reflection functionality and is the primary way to access metadata. Use the members of Type to get information about a type declaration, such as the constructors, methods, fields, properties, and events of a class, as well as the module and the assembly in which the class is deployed. The C# typeof operator (GetType operator in Visual Basic, typeid operator in Visual C++) returns a Type object.

> reonid © (11.10.07 13:33) [159]
> > etc (11.10.07 13:20) [158]
> Спасибо. Буду знать.
> Интересно, имеет смысл наследник этого типа, написанный
> пользователем?
> Иначе сей факт это всего лишь деталь реализации...
>
> > oxffff © (11.10.07 13:19) [157]
>
> Тогда эта фраза
> >> Поэтому методы System.Type являются аналогами классовых
> методов
> имеет смысл: это разные вещи, но и те, и другие применяются
>
> для доступа к метаданным. Больше между ними ничего общего
> нет.
>
> Но область применения дельфийских классовых методов,
> вообще говоря, метаданными не ограничивается.
> А как же пользовательские виртуальные классовые методы?

Так классовые методы нужны для доступа к метаданным класса.
Для typinfo тоже есть процедуры, но они в typinfo.
Они также принимают параметр typeinfo.
Они являются также типовыми процедурами (классовые методы в виде процедуры).
Абстрагируйтесь.
Просто в .NET Хейлберг слил все один тип.

Оно и понятно, кто сейчас захочет переписать System.pas?.
Хотя потенциально работы не много.
Но только прощай совместимость. :)

> oxffff © (11.10.07 13:58) [165]
>
> > isasa © (11.10.07 13:54) [163]
>
>
> Тогда как объяснить oxffff © (11.10.07 13:48) [162]
> третий if сверху.

То есть второй показывает, что типы String и Int32 не идентичны.
А третий показывает, идентичность типов для типов string и Int32.
Хотя да наследовали один тип от system.Type и все в нем реализовали и он называется RuntimeType.

static void Main(string[] args)
{
String A="abc";
String C = "asdasd";
Int32 B=0;

Console.WriteLine(A.GetType().ToString());
Console.WriteLine(B.GetType().ToString());
Console.WriteLine(C.GetType().ToString());
Console.WriteLine(A.GetType().GetType().ToString());
Console.WriteLine(B.GetType().GetType().ToString());

if (A.GetType() == C.GetType())
{
Console.WriteLine(A.GetType().ToString());
Console.WriteLine(C.GetType().ToString());
}
if (A.GetType() == B.GetType())
{
B = B + 2;
}
if (A.GetType().GetType()==B.GetType().GetType())
{
B=B+4;
}

}

> oxffff © (11.10.07 13:58) [165]

Не доцитировано.

Type is an abstract base class that allows multiple implementations. The system will always provide the derived class RuntimeType.

> euru © (11.10.07 14:09) [167]
>
> > oxffff © (11.10.07 13:58) [165]
>
> Не доцитировано.
>
> Type is an abstract base class that allows multiple implementations.
> The system will always provide the derived class RuntimeType.
>

Проверено. Подтверждаю
oxffff © (11.10.07 14:08) [166]

oxffff © (11.10.07 13:58) [165]
:)
Только тем, что
(тип для типов совпадают)
совпадают. Следовало ожидать, т.к. и тот и другой Referense Based (MarshalByRefObject)

> isasa © (11.10.07 14:11) [169]
> oxffff © (11.10.07 13:58) [165]
> :)
> Только тем, что
> (тип для типов совпадают)
> совпадают. Следовало ожидать, т.к. и тот и другой Referense
> Based (MarshalByRefObject)

Int32 у меня не box-овый.
А тип MarshalByRefObject вообще не к месту.

Что то я не понял вас?

Кажется понял.
Для remote objects для доступа к metadata могут сделать другой, делегирующий потомок от System.Type?

2oxffff © (11.10.07 13:56) [164]
> Так классовые методы нужны для доступа к метаданным класса.

Ну вот, приехали...
Вообще-то, в дельфях классовые методы с успехом
использовались и для других целей.

>>reonid © (11.10.07 14:55) [172]
А кстати для чего?
Я в основном использую для того чтобы создать экземпляры класса выбираемого в во время выполнения.
И в исходниках из ...Delphi\Source\* применяют в основном для тогоже

> reonid © (11.10.07 14:55) [172]
> 2oxffff © (11.10.07 13:56) [164]
> > Так классовые методы нужны для доступа к метаданным класса.
>
>
> Ну вот, приехали...
> Вообще-то, в дельфях классовые методы с успехом
> использовались и для других целей.

Угу. Не связанных с самим типом.
Может посмотреть все классовые методы Tobject и сделать выводы.
Если вы их использовали не по назначениею, то это тоже самое, что использовать методы (в том числе и виртуальные) объекта для доступа к глобальным переменным.
Все же их назначение работа с метаклассом.

> vpbar © (11.10.07 15:12) [173]
> >>reonid © (11.10.07 14:55) [172]
> А кстати для чего?
> Я в основном использую для того чтобы создать экземпляры
> класса выбираемого в во время выполнения.
> И в исходниках из ...Delphi\Source\* применяют в основном
> для тогоже

Виртуальные классовые удобно использовать для своих целей.
Для обеспечения полиморфного поведния без явного создания экземпляров.
(метакласс создаст за нас компилятор)

>>oxffff © (11.10.07 15:16) [174]
Извините что в мешиваюсь, если у вас диалог. Но посмотрел на это - все , кроме class function NewInstance: TObject; virtual; который иногда нужно переопределять, - костыли. Все это можно было бы добавить в язык и реализовать в компиляторе. Все равно определить свой TObject неполучится, т.к. модифицировать всякие vmt вроде нельзя. Буду рад если ошибаюсь.

> vpbar © (11.10.07 15:36) [176]
> >>oxffff © (11.10.07 15:16) [174]
> Извините что в мешиваюсь, если у вас диалог. Но посмотрел
> на это - все , кроме class function NewInstance: TObject;
> virtual; который иногда нужно переопределять, - костыли.
> Все это можно было бы добавить в язык и реализовать в
> компиляторе. Все равно определить свой TObject неполучится,
> т.к. модифицировать всякие vmt вроде нельзя. Буду рад если
> ошибаюсь.

Можно подробней. Я что то не понял. Где костыли?

>>oxffff © (11.10.07 15:38) [178]
В том смысле что можно было, например, добавить ключевое слово parent (или сделать его втроенным методом классов) и реализацию
class function TObject.ClassParent: TClass;
{$IFDEF PUREPASCAL}
begin
Pointer(Result) := PPointer(Integer(Self) + vmtParent)^;
if Result <> nil then
Pointer(Result) := PPointer(Result)^;
end;

Не описывать, а запрятать внутрь компилятора. Все равно тут идет обращение к структурам (PPointer(Integer(Self) + vmtParent)^) которые (если не ошибаюсь) доступны для изменения только компилятору

>>vpbar © (11.10.07 15:55) [179]
А костылями назвал, потомучто классовые методы TObject вроде ClassParent реализуют ОО модель языка, бессмысленны для переопределения и могли бы (и ИМХО так былобы логичнее) быть вынесены в грамматику.

> vpbar © (11.10.07 15:55) [179]
> >>oxffff © (11.10.07 15:38) [178]
> В том смысле что можно было, например, добавить ключевое
> слово parent (или сделать его втроенным методом классов)
> и реализацию
> class function TObject.ClassParent: TClass;
> {$IFDEF PUREPASCAL}
> begin
> Pointer(Result) := PPointer(Integer(Self) + vmtParent)^;
>
> if Result <> nil then
> Pointer(Result) := PPointer(Result)^;
> end;
>
> Не описывать, а запрятать внутрь компилятора. Все равно
> тут идет обращение к структурам (PPointer(Integer(Self)
> + vmtParent)^) которые (если не ошибаюсь) доступны для изменения
> только компилятору

Так если classparent поменять на parent ничего же не измениться.
Здесь вся идеалогия, в том что создание экзепляра типа или операции над типом (например финализация, получение интерфейса и т.д.) делегирована ответственному за это объекту (метаклассу).

>Не описывать, а запрятать внутрь компилятора. Все равно тут идет >обращение к структурам (PPointer(Integer(Self) + vmtParent)^) которые
>елли не ошибаюсь) доступны для изменения только компилятору

Да. вы правы.
за это ответственен компилятор.

>>oxffff © (11.10.07 16:05) [181]
Дело в том что я не вижу метаклассов в делфи. Они там виртуальные какие то - есть только на момент компиляции. Есть ссылка на класс class of, но метоклассом это я не считаю.

>>Здесь вся идеалогия, в том что создание экзепляра типа или операции над типом (например финализация, получение интерфейса и т.д.) делегирована ответственному за это объекту (метаклассу)
В данном случае метакласс - это TObject?

> В чём прикол class function?
>
> vpbar © (11.10.07 16:03) [180]
> >>vpbar © (11.10.07 15:55) [179]
> А костылями назвал, потомучто классовые методы TObject вроде
> ClassParent реализуют ОО модель языка, бессмысленны для
> переопределения и могли бы (и ИМХО так былобы логичнее)
> быть вынесены в грамматику.

Так если внести их в грамматику ничего же не поменяется.

vpbar © (11.10.07 16:08) [182]

> Дело в том что я не вижу метаклассов в делфи

То, что находится перед class of и есть метакласс (я так думаю (с))

> vpbar © (11.10.07 16:08) [182]
> >>oxffff © (11.10.07 16:05) [181]
> Дело в том что я не вижу метаклассов в делфи. Они там виртуальные
> какие то - есть только на момент компиляции. Есть ссылка
> на класс class of, но метоклассом это я не считаю.

например
var a:Tclass;

A-Это и есть экземпляр метакласса.

> В данном случае метакласс - это TObject?

Нет.
Зайди в help Memory Management\Internal Data Formats найди Class Types.
Если хочешь понять досконально, то проследи под отладчиком все цепочку создания и разрушения объекта.

>>oxffff © (11.10.07 16:09) [183]
Нуу. В частности поменяется ответ на oxffff © (11.10.07 15:16) [174]
Останутся только виртуальные классовые методы которые отвечают за выделение памяти. Т.е создание объекта.
А это "Все же их назначение работа с метаклассом." будет видно что работа с метаклассом (от тут один :) ) сводится к языковым средствам получения предка, имени класса т.е. того, что является частью модели ООП в делфи.

2vpbar © (11.10.07 16:08) [182]
Вы, насколько я подозреваю, никогда не работали со
списками классов (метаклассов) в дельфях.
Иногда, например, в списке классов нужно
выбрать первый, удовлетворяющий определённому критерию,
и создать экземпляр.
Например, поддерживающий определённую сигнатуру.
Для этого иногда полезно запросить у класса некоторую
виртуальную информацию до создания экземпляра.

> reonid © (11.10.07 16:28) [187]
> 2vpbar © (11.10.07 16:08) [182]
> Вы, насколько я подозреваю, никогда не работали со
> списками классов (метаклассов) в дельфях.
> Иногда, например, в списке классов нужно
> выбрать первый, удовлетворяющий определённому критерию,
>
> и создать экземпляр.
> Например, поддерживающий определённую сигнатуру.
> Для этого иногда полезно запросить у класса некоторую
> виртуальную информацию до создания экземпляра.

И эта операция должна быть именно полиморфной (предоставление информации о типе).
Я согласен с тем, что в этом отношении это очень удобно.

Просто думаю, что - это было следствие Newinstance. Я не думаю, что в тот момент(давным давно) они это так продумали.
Почему, то они не захотели расширять структуру метакласса. И тогда достаточно было бы и невиртуального метода.

> vpbar © (11.10.07 16:24) [186]
> >>oxffff © (11.10.07 16:09) [183]
> Нуу. В частности поменяется ответ на oxffff © (11.10.07
> 15:16) [174]
> Останутся только виртуальные классовые методы которые отвечают
> за выделение памяти. Т.е создание объекта.
> А это "Все же их назначение работа с метаклассом." будет
> видно что работа с метаклассом (от тут один :) ) сводится
> к языковым средствам получения предка, имени класса т.е.
> того, что является частью модели ООП в делфи

Так невиртуальные методы не занимают слотов метакласса. Поскольку линкуются на этапе компиляции.
Но!!! Они работают с классом и должны находиться в class scope.
Я так думаю. Но даже если бы было бы, как предлагаете вы, то внутренне(технически) - это было бы тоже самое.

> Почему, то они не захотели расширять структуру метакласса.
> И тогда достаточно было бы и невиртуального метода.

Ну в известном смысле виртуальный классовый метод ее расширяет.

>>Игорь Шевченко © (11.10.07 16:18) [184]
>>oxffff © (11.10.07 16:18) [185]
Я понял это дуализм - я считаю что это ссылка на класс и это так вы считаете что это метакласс и это так.
Т.е: var AAA:Tclass; // где Tclass=clas of Tobject AAA - ссылка на класс Tobject.

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

>>oxffff © (11.10.07 16:41) [189]
>>Так невиртуальные методы не занимают слотов метакласса.
Вах какие новые термины. Но суть понятна. Видимо в [191] я пришол к правильному выводу что такое метакласс.

>>reonid © (11.10.07 16:28) [187]
Ошибаетесь, бывало использовал список указателей на класс.
"списками классов (метаклассов) в дельфях"
Так у вас класс и метакласс одно и тоже?

> И единственно что я могу назвать тут метаклассом - это VMT.
> хотя это на мой взгляд странно.

метакласс - это поля по отрицательному смещению от VMT +связанные с этими полями структруы +все классовые методы. Если грубо классифицировать.
Причем классовые виртуальные и экземплярные виртуальные идут вперемешку.

-76
Pointer
pointer to virtual method table (or nil)

-72
Pointer
pointer to interface table (or nil)

-68
Pointer
pointer to Automation information table (or nil)

-64
Pointer
pointer to instance initialization table (or nil)

-60
Pointer
pointer to type information table (or nil)

-56
Pointer
pointer to field definition table (or nil)

-52
Pointer
pointer to method definition table (or nil)

-48
Pointer
pointer to dynamic method table (or nil)

-44
Pointer
pointer to short string containing class name

-40
Cardinal
instance size in bytes

-36
Pointer
pointer to a pointer to ancestor class (or nil)

>>oxffff © (11.10.07 16:59) [194]
Ок. Наконец мне ответили как тут понимается термин "метаклас".
Просто я понимал термин метаклас несколько иначе. Так ка возможно в динамически языках. Когда метаклас может создавать класс во время выполнения. И класс является экземпляром метакласса.

В делфи же все классы заданы на момент компиляции. И делфийский метакласс совпадает с классом. Ведь по сути "поля по отрицательному смещению от VMT +связанные с этими полями структруы +все классовые методы" так же относятся и к классу.
Поэтому конструкцию class of мне удобно рассматривать как ссылку на класс (VMT), которая позволяет ссылаться на класс и совместимые с ним классы и выбирать из, но не создавать.

2vpbar © (11.10.07 16:58) [193]
Термин "метакласс" для дельфи не родной,
а писать везде ссылка на класс слишком долго,
поэтому я использовал слово класс, и, чтобы избежать
недоразумений, подчеркнул, что я использую его
в смысле метакласс (или ссылка на класс).
Мне казалось, в контексте обсуждения это будет понятно.

>Ошибаетесь, бывало использовал список указателей на класс.
Вы имеете ввиду список указателей на объекты (экземпляры)?

>>reonid © (11.10.07 17:11) [196]

>>Вы имеете ввиду список указателей на объекты (экземпляры)?
Что имею то и...
"список указателей на класс."
Объект - экземпляр класса.
Указатель на объект бессмысленен ибо сам объект указатель.
ЗЫ
Хоть в делфи запутанно кроме class есть еще object. Но
Но такое
" _TObj = object protected procedure Init; virtual; public function VmtAddr: Pointer; end;" (C) Vladimir Kladov, 2000-2003.
щас редко используется. Поэтому вы имели ввиду всетаки под объектом экземпляр класса.

vpbar © (11.10.07 17:22) [197]
>сам объект указатель.
На самом объект - не указатель, а то, что на что тот указывает.
А переменную объектного типа правильнее было бы называть
ссылкой на объект. Просто для простоты слово "ссылка" обычно
опускают. (Как и я опустил её в словосочетании "ссылка на класс").

>Просто я понимал термин метаклас несколько иначе. Так ка возможно в >динамически языках. Когда метаклас может создавать класс во время >выполнения. И класс является экземпляром метакласса.

В самой среде Дельфи именно так организована возможность
подключения пакетов и добавления компонентов из них.
И то же самое можно сделать и в пользовательских приложениях.

> vpbar © (11.10.07 17:07) [195]
> >>oxffff © (11.10.07 16:59) [194]
> Ок. Наконец мне ответили как тут понимается термин "метаклас".
>
> Просто я понимал термин метаклас несколько иначе. Так ка
> возможно в динамически языках. Когда метаклас может создавать
> класс во время выполнения. И класс является экземпляром
> метакласса.

.Net может создавать класс на основе параметризованного класса в Run-time.

В чём прикол class function? Найти похожие ветки