In our previous episode, dmitry boyarintsev said:
> >> file, but the only they to see a full declaration is via documention,
> >> rather than header-sources.
> >
> > I don't understand this.
>
> Delphi can compile a project with dcu present, but no .pas files.
> Any type or routine present in dcu
On Tue, Oct 20, 2009 at 12:03 PM, Paul Ishenin wrote:
> Can the mail topic be changed for the unrelated thread? I still expect a new
> dose of criticism in every mail with the current topic.
You're right, i've been hijacking the thread to a wrong subject.
Sorry, won't happen again.
thanks,
dmitry
dmitry boyarintsev wrote:
Delphi can compile a project with dcu present, but no .pas files.
...
Can the mail topic be changed for the unrelated thread? I still expect a
new dose of criticism in every mail with the current topic.
Best regards,
Paul Ishenin.
__
On Tue, Oct 20, 2009 at 11:26 AM, Marco van de Voort wrote:
>> Some class/vars/consts/functions are avaiable and declared in package
>> file, but the only they to see a full declaration is via documention,
>> rather than header-sources.
>
> I don't understand this.
Delphi can compile a project wi
In our previous episode, dmitry boyarintsev said:
> > Packages don't have external classes. ?A package is fully transparent to the
> > program, IOW when linking to a package there are proper .ppu's and
> > everything, and there is no "external" link step.
>
> So it would be like using delphi's dcu
On Tue, Oct 20, 2009 at 1:22 PM, Marco van de Voort wrote:
> Packages don't have external classes. A package is fully transparent to the
> program, IOW when linking to a package there are proper .ppu's and
> everything, and there is no "external" link step.
So it would be like using delphi's dcu
Florian Klaempfl :
> It's not only not visible but neither accessible.
For good reasons, usually. Either there's a way to access it (properties) or it
really is an implementation detail that might change.
> And if something is
> not accessible, it affects flexibility.
Yes. [That's one reason w
In our previous episode, dmitry boyarintsev said:
> > specially for minor features is more trouble then it is worth, since
> > eventually the Delphi syntax will have to be supported anyway.
> Agreed, and that's quite sad, eventual Delphi syntax support makes
> FreePascal actually FreeDelphi.
I don
On Tue, Oct 20, 2009 at 11:20 AM, Marco van de Voort wrote:
> Please no. While I directly agree it is better, having incompatible syntax,
> specially for minor features is more trouble then it is worth, since
> eventually the Delphi syntax will have to be supported anyway.
Agreed, and that's quite
Florian Klaempfl wrote:
Vinzent Höfler schrieb:
Florian Klaempfl :
Marco van de Voort schrieb:
In our previous episode, Florian Klaempfl said:
This is exactly my point about sealed classes. When you design the
product or class, you have NO way of know what will come i
Vinzent Höfler schrieb:
> Florian Klaempfl :
>
>> Marco van de Voort schrieb:
>>> In our previous episode, Florian Klaempfl said:
> This is exactly my point about sealed classes. When you design the
> product or class, you have NO way of know what will come in the
> future. So you need
In our previous episode, dmitry boyarintsev said:
> > What we will get in the result of this language simplification? Yes,
> > extremely fast and easy compiler but do you like it?
>
> Maybe the syntax should be simplified, rather than following new
> delphi's .Nettist growing style? AFAIK, it's be
On Tue, Oct 20, 2009 at 17:59, dmitry boyarintsev
wrote:
> On Tue, Oct 20, 2009 at 4:59 AM, Paul Ishenin wrote:
> Maybe the syntax should be simplified, rather than following new
> delphi's .Nettist growing style? AFAIK, it's been discussed about
> using class attributes.
Excellent idea, and I e
On Tue, Oct 20, 2009 at 4:59 AM, Paul Ishenin wrote:
> What we will get in the result of this language simplification? Yes,
> extremely fast and easy compiler but do you like it?
Maybe the syntax should be simplified, rather than following new
delphi's .Nettist growing style? AFAIK, it's been dis
Mattias Gärtner wrote:
True.
But as already mentioned:
It does not hurt.
Granted, the compiler became somewhat bigger and slower, in fact all
pascal parsers became somewhat bigger and slower (fcl, codetools,
highlighters, ...), a new modifier bites some existing code, the
documentation become
Zitat von Vinzent Höfler :
Florian Klaempfl :
Marco van de Voort schrieb:
> In our previous episode, Florian Klaempfl said:
>>> This is exactly my point about sealed classes. When you design the
>>> product or class, you have NO way of know what will come in the
>>> future. So you need to stay
Florian Klaempfl :
> Marco van de Voort schrieb:
> > In our previous episode, Florian Klaempfl said:
> >>> This is exactly my point about sealed classes. When you design the
> >>> product or class, you have NO way of know what will come in the
> >>> future. So you need to stay flexible to change!
Marco van de Voort schrieb:
> In our previous episode, Florian Klaempfl said:
>>> This is exactly my point about sealed classes. When you design the
>>> product or class, you have NO way of know what will come in the
>>> future. So you need to stay flexible to change! Yet another OOP
>>> principal
In our previous episode, Florian Klaempfl said:
> > This is exactly my point about sealed classes. When you design the
> > product or class, you have NO way of know what will come in the
> > future. So you need to stay flexible to change! Yet another OOP
> > principal that "sealed" tries to prevent
Paul Ishenin :
> Vinzent Höfler wrote:
> > And then inside the implementation:
> >
> > TNokia3720Phone.SomeMethod;
> > begin
> >case self.Edition of
> > n3720peStandard:
> > ImplementedThatWay;
> > n3720peDeluxe:
> > ImplementedThisWay;
> >end;
> > end;
> >
On Monday 19 October 2009 15:35:53 Paul Ishenin wrote:
> Vinzent Höfler wrote:
> > And then inside the implementation:
> >
> > TNokia3720Phone.SomeMethod;
> > begin
> >case self.Edition of
> > n3720peStandard:
> > ImplementedThatWay;
> > n3720peDeluxe:
> > Implemen
On 19 Oct 2009, at 16:09, Paul Ishenin wrote:
Jonas Maebe wrote:
In that case, an entry should be added at
http://wiki.freepascal.org/User_Changes_Trunk
Is this ok: http://wiki.lazarus.freepascal.org/User_Changes_Trunk#Abstract_abd_Sealed_classe_modifiers
?
Yes, thanks. I've modified it a
Jonas Maebe wrote:
In that case, an entry should be added at
http://wiki.freepascal.org/User_Changes_Trunk
Is this ok:
http://wiki.lazarus.freepascal.org/User_Changes_Trunk#Abstract_abd_Sealed_classe_modifiers
?
Best regards,
Paul Ishenin.
___
fpc-d
Vinzent Höfler wrote:
And then inside the implementation:
TNokia3720Phone.SomeMethod;
begin
case self.Edition of
n3720peStandard:
ImplementedThatWay;
n3720peDeluxe:
ImplementedThisWay;
end;
end;
When you are phone manufacturer you know you model line very w
On 19 Oct 2009, at 05:25, Marco van de Voort wrote:
In our previous episode, Paul Ishenin said:
If we want to port code which is made for the recent delphi we need
to
support it syntax. Delphi has "sealed". Why should we invent
something
uncompatible?
For delphi compatibility we only ne
> Vinzent Höfler wrote:
>
> > And what is with the TNokia3720Phone_DeluxeEdition which is basically
> the same as TNokia3720Phone, but with some enhanced features?
> >
> TNokia3720PhoneEdition = (n3720peStandard, n3720peDeluxe);
> TNokia3720Phone = class sealed(...)
> public
> property Edition
Vinzent Höfler wrote:
And what is with the TNokia3720Phone_DeluxeEdition which is basically the same
as TNokia3720Phone, but with some enhanced features?
TNokia3720PhoneEdition = (n3720peStandard, n3720peDeluxe);
TNokia3720Phone = class sealed(...)
public
property Edition: TNokia3720PhoneEd
Paul Ishenin :
> Alexander Klenin wrote:
>
> > Sure, and then company releases Nokia 3721, and some hapless developer
> in India
> > have to reimplement the entire TNokia3720Phone class.
> > This is classis example of why sealed is bad ;-)
>
> But what if Nokia company requires this? How you wil
Paul Ishenin :
> TBasicPhone = class abstract
> TCellularPhone = class(TBasicPhone)
> TSatelitePhone = class(TBasicPhone)
> TDialPhone = class(TBasicPhone)
> ...
> TNokiaPhone = class(TCellularPhone)
> TNokia37xxPhone = class(TNokiaPhone)
> TNokia3720Phone = class sealed(TNokia37xxPhone)
>
> TBas
On Mon, Oct 19, 2009 at 20:30, dmitry boyarintsev
wrote:
> Please forgive me my ignorance, but what is advantage of using sealed classes?
> Personally, i see no advantage of forbidding inheritance of some class.
>
> What should be the **proper** use of sealed classes and class helpers?
>
> Please
dmitry boyarintsev wrote:
Please forgive me my ignorance, but what is advantage of using sealed classes?
Personally, i see no advantage of forbidding inheritance of some class.
What should be the **proper** use of sealed classes and class helpers?
Please note, i'll probably copy-paste all answe
Alexander Klenin wrote:
Of course. Still, Jonas is right, this should be mentioned in wiki.
I don't argue but I want to wait while this discussion will fade a bit.
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepascal.
2009/10/19 Marco van de Voort :
> In our previous episode, Paul Ishenin said:
>> > I don't believe in that magnitude of control, and for meaning we typically
>> > use comments, not language features.
>>
>> Comments are language features too. Treat sealed as a strong comment for
>> those who don't r
On Mon, Oct 19, 2009 at 20:27, Paul Ishenin wrote:
> Alexander Klenin wrote:
>
>> This is not the question of terminology (though I think the proper
>> term in this case is "non-reserved keyword"), but of the fact that
>> some programs that compiled previously will stop compiling after that
>> pat
Please forgive me my ignorance, but what is advantage of using sealed classes?
Personally, i see no advantage of forbidding inheritance of some class.
What should be the **proper** use of sealed classes and class helpers?
Please note, i'll probably copy-paste all answers to the wiki.
thanks,
dmi
Alexander Klenin wrote:
This is not the question of terminology (though I think the proper
term in this case is "non-reserved keyword"), but of the fact that
some programs that compiled previously will stop compiling after that patch.
I don't believe there are programs which have classes with
On 19 Oct 2009, at 10:59, Alexander Klenin wrote:
On Mon, Oct 19, 2009 at 19:35, Jonas Maebe
wrote:
Are they real keywords in Delphi? E.g., a lot of modifiers such as
"default"
and "register" are not keywords. You can perfectly declare
variables of
procedures with these names.
This i
On 19/10/2009, Alexander Klenin wrote:
> some programs that compiled previously will stop compiling after that patch.
>
It's called evolution. I've just spent two days updating "previously
working code" to cater for refactored and slightly modified code from
a external library that I use.
It's
On Monday 19 October 2009 10:47:40 Peter Popov wrote:
> > All features being equal, I would rather have class constants and class
> > types
> > included in FPC.
>
> Class constants are exceptionally bad idea: I've seen a guy define
> PI=3.1415... inside a C++ class! The same functionality already e
On Mon, Oct 19, 2009 at 19:35, Jonas Maebe wrote:
>
> On 17 Oct 2009, at 08:22, Paul Ishenin wrote:
>
>> Alexander Klenin wrote:
>>>
>>> 3) This patch introduces new keyword -- what about backwards
>>> compatibility? The code like:
>>> type T = class sealed: Boolean; end;
>>> will stop compiling
Jonas Maebe wrote:
Are they real keywords in Delphi? E.g., a lot of modifiers such as
"default" and "register" are not keywords. You can perfectly declare
variables of procedures with these names.
You can use sealed/abstract where you want in fpc too. Except only given
previosly example.
B
All features being equal, I would rather have class constants and class
types
included in FPC.
Class constants are exceptionally bad idea: I've seen a guy define
PI=3.1415... inside a C++ class! The same functionality already exists in
fpc: define a (class, inline) function returning the
On Mon, 19 Oct 2009, Jonas Maebe wrote:
On 17 Oct 2009, at 08:22, Paul Ishenin wrote:
Alexander Klenin wrote:
3) This patch introduces new keyword -- what about backwards
compatibility? The code like:
type T = class sealed: Boolean; end;
will stop compiling after the patch. Maybe it is bet
On 17 Oct 2009, at 08:22, Paul Ishenin wrote:
Alexander Klenin wrote:
3) This patch introduces new keyword -- what about backwards
compatibility? The code like:
type T = class sealed: Boolean; end;
will stop compiling after the patch. Maybe it is better to use
another syntax?
Same with an
On 19/10/2009, Alexander Klenin wrote:
>
>
> Why sealing a singleton is any more (or less) useful then sealing any
> other class?
> I use hierarchies of singletons quite often, and having them sealed would
> hurt.
>
Then simply don't use "sealed". Or use "sealed" on you last class
definitions
On 19/10/2009, Florian Klaempfl wrote:
>
> After all there are a couple of reasons to add it
> - Delphi compatibility
> - at least the singleton pattern
> - commercial packages
> - possible optimization without wpo
Good enough for me. :-)
> See
>
> http://github.com/graemeg/freepascal/co
On Mon, Oct 19, 2009 at 18:40, Florian Klaempfl wrote:
> Alexander Klenin schrieb:
>> Why sealing a singleton is any more (or less) useful then sealing any
>> other class?
>
> As I said, it's as usefull as private/protected/strict private/strict
> protected imo
Well, the problem is that sealed i
Alexander Klenin schrieb:
> On Mon, Oct 19, 2009 at 17:55, Florian Klaempfl
> wrote:
>> Without discussing details, I think a singleton is a good example where
>> sealed is useful.
>
> Why sealing a singleton is any more (or less) useful then sealing any
> other class?
As I said, it's as useful
On Mon, Oct 19, 2009 at 17:55, Florian Klaempfl wrote:
> Without discussing details, I think a singleton is a good example where
> sealed is useful.
Why sealing a singleton is any more (or less) useful then sealing any
other class?
I use hierarchies of singletons quite often, and having them seal
Graeme Geldenhuys schrieb:
> On 19/10/2009, Florian Klaempfl wrote:
>> Without discussing details, I think a singleton is a good example where
>> sealed is useful.
>
>
> You had to go and pick the one design pattern that is probably the
> most difficult to implement (per GoF book) in any langua
On 19/10/2009, Florian Klaempfl wrote:
>
> Without discussing details, I think a singleton is a good example where
> sealed is useful.
You had to go and pick the one design pattern that is probably the
most difficult to implement (per GoF book) in any language. :-)
There are various other ways
Hi guys,
The one situation that I have encountered where a sealed class would be useful
is where a class exists that need to be private to a class library or another
class, and must be shared between multiple units and where any attempt to
override some of its functionality will cause problems
Graeme Geldenhuys schrieb:
> 2009/10/19 Paul Ishenin :
>> ...
>> TNokiaPhone = class(TCellularPhone)
>> TNokia37xxPhone = class(TNokiaPhone)
>> TNokia3720Phone = class sealed(TNokia37xxPhone)
>>
>> TBasicPhone is ofcource an abstract class. It can have some basic fields
>> like color, weight, dimen
Graeme Geldenhuys wrote:
Bad example! :-)
Quality of this example varies according to the initial POV you have.
I have the Nokia 5800XM. You get that "final model"
in two flavours. Red and Blue (phone color and software theme color).
Then you also get revisions of that phone. Revision 1 had
2009/10/19 Paul Ishenin :
> ...
> TNokiaPhone = class(TCellularPhone)
> TNokia37xxPhone = class(TNokiaPhone)
> TNokia3720Phone = class sealed(TNokia37xxPhone)
>
> TBasicPhone is ofcource an abstract class. It can have some basic fields
> like color, weight, dimensions, ...
> TNokia3720Phone is a fi
Alexander Klenin wrote:
Sure, and then company releases Nokia 3721, and some hapless developer in India
have to reimplement the entire TNokia3720Phone class.
This is classis example of why sealed is bad ;-)
But what if Nokia company requires this? How you will limit that India
developer then?
On Mon, Oct 19, 2009 at 15:43, Paul Ishenin wrote:
> Except the security role sealed and abstract classes have their important
> oop meaning.
Security is only possible in the context of languages like Java, which can
actually enforce visibility rules at run-time. Compiled languages nave
no such a
Marco van de Voort wrote:
That's the weakest motivation for a language feature that I ever saw.
"comment for people that don't read comments) :-)
That's just one of applications for this feature since you don't want to
believe in others.
Best regards,
Paul Ishenin.
___
In our previous episode, Paul Ishenin said:
> > I don't believe in that magnitude of control, and for meaning we typically
> > use comments, not language features.
>
> Comments are language features too. Treat sealed as a strong comment for
> those who don't read comments.
That's the weakest mot
Marco van de Voort wrote:
I don't believe in that magnitude of control, and for meaning we typically
use comments, not language features.
Comments are language features too. Treat sealed as a strong comment for
those who don't read comments.
Best regards,
Paul Ishenin.
In our previous episode, Paul Ishenin said:
>
> > For delphi compatibility we only need to skip it. I agree mostly with Jonas
> > here, I think this is one of those access control things added by popular
> > demand (because language xxx has it).
>
> Maybe in open source world sealed classes has s
Marco van de Voort wrote:
For delphi compatibility we only need to skip it. I agree mostly with Jonas
here, I think this is one of those access control things added by popular
demand (because language xxx has it).
Maybe in open source world sealed classes has small meaning since you
can alway
In our previous episode, Paul Ishenin said:
> > So, maybe one should "seal" entire units instead of classes, meaning
> > they provide import definitions of some other OOP framework to be used
> > but not abused. Maybe use "imported" instead of "sealed".
>
> If we want to port code which is made
Peter Popov wrote:
So, maybe one should "seal" entire units instead of classes, meaning
they provide import definitions of some other OOP framework to be used
but not abused. Maybe use "imported" instead of "sealed".
If we want to port code which is made for the recent delphi we need to
supp
The discussion on sealing is interesting. Following up on the remarks of
sergei I can see one benefit of sealing classes:
Suppose you have a C++ OOP framework, such as Qt, which one wishes to use
in Delphi. There are a number of ways to do this. So, suppose one goes for
the path in which th
Jonas Maebe schrieb:
> Declaring a class as "sealed" for optimization purposes is a
> micro-optimization that pollutes the source code. In that case, you'll
> probably have to revert that change again later if you or someone else
> does have to inherit from the class after all. It may also force pe
Florian Klaempfl wrote on Sun, 18 Oct 2009:
Jonas Maebe schrieb:
Florian Klaempfl wrote on Sat, 17 Oct 2009:
Graeme Geldenhuys schrieb:
Would you mind explaining this - I never saw the benefit of a sealed
class.
From a compiler developers point of view, it makes optimization easier
under
Jonas Maebe schrieb:
> Florian Klaempfl wrote on Sat, 17 Oct 2009:
>
>> Graeme Geldenhuys schrieb:
>>> 2009/10/16 Paul Ishenin :
Sealed class is a class which can't be derived by another class.
This one is
fully supported by delphi.
>>>
>>> Would you mind explaining this - I never s
On Sun, Oct 18, 2009 at 07:28, Jonas Maebe wrote:
> FPC can already do this automatically for all classes in the entire program
> with whole-program optimization. You don't need sealed classes for this
> (they might slightly improve those optimizations, but I doubt it will be
> noticeable in real
Florian Klaempfl wrote on Sat, 17 Oct 2009:
Graeme Geldenhuys schrieb:
2009/10/16 Paul Ishenin :
Sealed class is a class which can't be derived by another class.
This one is
fully supported by delphi.
Would you mind explaining this - I never saw the benefit of a sealed
class.
From a com
AFAIK the rationale for a sealed class is that it can not be extended.
In big shops that has an advantage in maintaining code. Also third
parties can "lock" their code.
f.e.:
TDoNotTouchMe = class sealed (TMyTouchableClass);
Means that if you use the former you cannot break code, if you use
On Saturday 17 October 2009, Florian Klaempfl wrote:
> Vinzent Höfler schrieb:
> > Florian Klaempfl :
> >> From a compiler developers point of view, it makes optimization
> >> easier under certain cases (e.g. virtual method calls). It's the
> >> same as with inline: inline has no advantage except t
Vinzent Höfler schrieb:
> Florian Klaempfl :
>
>> From a compiler developers point of view, it makes optimization easier
>> under certain cases (e.g. virtual method calls). It's the same as with
>> inline: inline has no advantage except that it is a hint to the compiler
>> how the code can be opti
Florian Klaempfl :
> From a compiler developers point of view, it makes optimization easier
> under certain cases (e.g. virtual method calls). It's the same as with
> inline: inline has no advantage except that it is a hint to the compiler
> how the code can be optimized.
I really doubt that "sea
Graeme Geldenhuys :
> 2009/10/16 Alexander Klenin :
> > "Class sealing allows extension of classes within a package, but
> > prevent clients from extending such classes outside of the package."
> > This might actually make some sense, see e.g. TBasicChartSeries class
> > in TAChart package.
>
> A
Graeme Geldenhuys schrieb:
> 2009/10/16 Paul Ishenin :
>> Sealed class is a class which can't be derived by another class. This one is
>> fully supported by delphi.
>
> Would you mind explaining this - I never saw the benefit of a sealed
> class.
>From a compiler developers point of view, it mak
dmitry boyarintsev wrote:
On Sat, Oct 17, 2009 at 8:36 AM, Paul Ishenin wrote:
Please look at example here: http://edn.embarcadero.com/article/34324
TMyClassHelper there has added HelloWorld and MyFunc to the TMyClass type.
But they're not part of VMT, aren't they?
I am not sure
On Sat, Oct 17, 2009 at 8:36 AM, Paul Ishenin wrote:
> Please look at example here: http://edn.embarcadero.com/article/34324
>
> TMyClassHelper there has added HelloWorld and MyFunc to the TMyClass type.
But they're not part of VMT, aren't they?
Can these helper methods be used in units other tha
dmitry boyarintsev wrote:
Obj-C categories are different to helper-classes.
Helper-classes don't extend class methods, they just provide a way to
access private/protected class section.
Categories actually are adding methods to a obj-c class.
Please look at example here: http://edn.embarcader
On Sat, Oct 17, 2009 at 7:55 AM, Paul Ishenin wrote:
> Class helpers will appear in fpc sooner or later too. As I heard they are
> needed (although a bit extended) for the Jonas objective pascal project.
Obj-C categories are different to helper-classes.
Helper-classes don't extend class methods,
Sergei Gorelkin wrote:
But as soon as a feature appears, it starts to be used (and abused,
too) here and there. Next come 'class helpers', the purpose of which
is to circumvent sealed classes, and so on...
Class helpers will appear in fpc sooner or later too. As I heard they
are needed (althoug
Alexander Klenin wrote:
2) parse_object_options consumes exactly one exemplar of either
"abstract" or "sealed".
actually, Delphi allows arbitrary number of these keywords (e.g.
"class abstract abstract").
This is pointless, but I think should be allowed for compatibility,
perhaps with a warni
On Sat, Oct 17, 2009 at 08:51, Sergei Gorelkin wrote:
> Guess its primary target are classes like Java/.NET String. These are value
> classes, they do not contain other pointers, garbage collection is therefore
> easier and the whole framework speeds up. If you inherit from it and add
> your own m
On Sat, Oct 17, 2009 at 08:06, Graeme Geldenhuys
wrote:
> 2009/10/16 Alexander Klenin :
>> "Class sealing allows extension of classes within a package, but
>> prevent clients from extending such classes outside of the package."
>> This might actually make some sense, see e.g. TBasicChartSeries cla
2009/10/16 Sergei Gorelkin :
>
> Sealing does not prevent reusing in form of aggregation (when the sealed
Aggregation is now always the best design. Inheritance is often used.
>
> These cases use precisely aggregation, so, in fact, the code of TObjectList,
> etc. wouldn't change if TList was sea
Graeme Geldenhuys пишет:
2009/10/16 Paul Ishenin :
Sealed class is a class which can't be derived by another class. This one is
fully supported by delphi.
Would you mind explaining this - I never saw the benefit of a sealed
class. Using myself as an example. Say I develop some kick-ass OOP
fra
2009/10/16 JoshyFun :
>
> I think it has been designed to avoid derived classes from commercial
> packages.
In that case, it just plain dumb! I don't know of a single commercial
package that doesn't benefit from extensions by external developers.
* Microsoft Shell (thousands)
* OS/2 Workplace Sh
Hello Graeme,
Friday, October 16, 2009, 11:01:42 PM, you wrote:
GG> Would you mind explaining this - I never saw the benefit of a sealed
GG> class. Using myself as an example. Say I develop some kick-ass OOP
GG> framework. There is no way in hell I can forsee every possible use of
GG> the classes
2009/10/16 Paul Ishenin :
>
> I tried to implement support for delphi sealed and abstract classes. They
> are described a bit here: http://edn.embarcadero.com/article/34324
Delphi's "sealed class" example is slightly flawed. :-)
--
Classes marked as sealed cannot be inherited
2009/10/16 Alexander Klenin :
> "Class sealing allows extension of classes within a package, but
> prevent clients from extending such classes outside of the package."
> This might actually make some sense, see e.g. TBasicChartSeries class
> in TAChart package.
As I said in my earlier reply. I don
2009/10/16 Paul Ishenin :
> Sealed class is a class which can't be derived by another class. This one is
> fully supported by delphi.
Would you mind explaining this - I never saw the benefit of a sealed
class. Using myself as an example. Say I develop some kick-ass OOP
framework. There is no way i
Alexander Klenin :
> 2) In OBJFPC mode, do not accept "abstract" keyword and change warning to
> error.
Please don't. At least in the past there were quite some classes in the FCL
that did not implement all declared methods (IIRC also in fpImage).
Honestly, sometimes I don't even know what they
On Sat, Oct 17, 2009 at 03:25, Paul Ishenin wrote:
> I tried to implement support for delphi sealed and abstract classes. They
> are described a bit here: http://edn.embarcadero.com/article/34324
First, let me say that I am very glad that you entered FPC development --
with your energy I hope it
Hello, FPC developers' list
This is my first compiler patch. So please be indulge.
I tried to implement support for delphi sealed and abstract classes.
They are described a bit here: http://edn.embarcadero.com/article/34324
At moment 'class abstract' in delphi do nothing although it should no
94 matches
Mail list logo
