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
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
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 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
On Mon, Oct 19, 2009 at 18:35, Florian Klaempfl wrote:
> And taking into account the size of the patch (see below and ignore the
> auto generated files msg*.inc), it's worth to add. private etc. cause
> much more trouble in the compiler and has no more real use imo.
>
>> By I guess this whole thre
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
Alexander Klenin schrieb:
> On Mon, Oct 19, 2009 at 18:35, Florian Klaempfl
> wrote:
>> And taking into account the size of the patch (see below and ignore the
>> auto generated files msg*.inc), it's worth to add. private etc. cause
>> much more trouble in the compiler and has no more real use im
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
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 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 Mon, Oct 19, 2009 at 18:44, Florian Klaempfl wrote:
> Alexander Klenin schrieb:
>> BTW, I have already asked in the beginning of the thread,
>> but got no answer: why are those files under version control at all?
>
> Because it's easier to handle when doing compiler development work
What is ea
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 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
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
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
Alexander Klenin schrieb:
> On Mon, Oct 19, 2009 at 18:44, Florian Klaempfl
> wrote:
>> Alexander Klenin schrieb:
>>> BTW, I have already asked in the beginning of the thread,
>>> but got no answer: why are those files under version control at all?
>> Because it's easier to handle when doing comp
Florian Klaempfl wrote:
I want really fast building and no external tool calling etc., that's
why I still use the text mode ide. Not to forget that msg*.inc not the
only auto generated files in the compiler sources: there are e.g.
autogenerated register tables and instruction tables so this adds
On 19 Oct 2009, at 10:44, Florian Klaempfl wrote:
I still think that none of the people mainly working on the compiler
use
lazarus :)
Actually, I mostly use Lazarus for working on the compiler nowadays,
because of its code navigation. I still build on the command line
using the makefile
Micha Nelissen schrieb:
> Florian Klaempfl wrote:
>> I want really fast building and no external tool calling etc., that's
>> why I still use the text mode ide. Not to forget that msg*.inc not the
>> only auto generated files in the compiler sources: there are e.g.
>> autogenerated register tables
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
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 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
Jonas Maebe schrieb:
>
> On 19 Oct 2009, at 10:44, Florian Klaempfl wrote:
>
>> I still think that none of the people mainly working on the compiler use
>> lazarus :)
>
> Actually, I mostly use Lazarus for working on the compiler nowadays,
> because of its code navigation.
I see :) I still navi
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
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
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
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
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
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.
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
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
ping!
Anybody? Especially Question 2...
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist - fpc-devel@lists.freepascal
Florian Klaempfl schreef:
Alexander Klenin schrieb:
On Mon, Oct 19, 2009 at 18:35, Florian Klaempfl wrote:
And taking into account the size of the patch (see below and ignore the
auto generated files msg*.inc), it's worth to add. private etc. cause
much more trouble in the compiler and has no
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
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
On Mon, 19 Oct 2009 04:02:45 -0500, 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 exists
in
fpc:
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
Peter Popov wrote:
That is my point: most constants are global in nature. It would be
interested to see a class constant which is usefull where a global
constant (within a unit) is not.
A class constant could be useful for a default value. Normally those are
all set in the constructor. But if
"Peter Popov" :
> PI exists, it has a unique transcedental value, so it should clearly be
> global. Semanticaly, MyClass1.PI and MyClass2.PI are different
> identifiers, which given the nature of PI is a ridiculous concept.
The unique transcendental value of PI can not be expressed within a f
> 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
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
Peter Popov пишет:
if OOP is about data encapsulation, why are we using global constants and
types?
You forget that units already provide one encapsulation level. This has
been a distinct feature of Pascal long before C++ introduced namespaces.
This means that Unit1.PI and Unit2.PI are two
On Monday 19 October 2009 13:26:34 Peter Popov wrote:
> On Mon, 19 Oct 2009 04:02:45 -0500, 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 gu
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
An example would be
TItemCache = class
private
const DEFAULT_CACHE_SIZE = 1024;
...
end;
sure a global value would do, but there is no need for the value to be
global.
Martin
This is a good example. However, the same paradigm can be achived by a
function:
function TItemCache.DEFAU
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
On Mon, Oct 19, 2009 at 9:18 AM, Peter Popov wrote:
>>
>> An example would be
>> TItemCache = class
>> private
>> const DEFAULT_CACHE_SIZE = 1024;
>> ...
>> end;
>>
>> sure a global value would do, but there is no need for the value to be
>> global.
>>
>> Martin
>
> This is a good example. Howe
On 19 Oct 2009, at 16:18, Peter Popov wrote:
An example would be
TItemCache = class
private
const DEFAULT_CACHE_SIZE = 1024;
...
end;
sure a global value would do, but there is no need for the value to
be global.
This is a good example. However, the same paradigm can be achived by
a f
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
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
Paul Ishenin :
> Vinzent Höfler wrote:
> > And then inside the implementation:
> >
> > TNokia3720Phone.SomeMethod;
> > begin
> >case self.Edition of
> > n3720peStandard:
> > ImplementedThatWay;
> > n3720peDeluxe:
> > ImplementedThisWay;
> >end;
> > end;
> >
I have a stupid question, but I can not for the life of me figure this out
quickly:
Recent official release of lazarus was 0.9.28, it is based on fpc 2.2.4-0.
The default widget se is gtk2. I'm trying to do a test where i am compiling
against gtk1, but i get a compiler error when trying to go bac
2009/10/19 Desmond Coertzen :
>
> The default widget se is gtk2. I'm trying to do a test where i am compiling
> against gtk1, but i get a compiler error when trying to go back to gtk1 :
> "Interfaces unit not found", but works fine when compiling gtk2. I didn't
Did you actually compile the LCL wit
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
On Tue, Oct 20, 2009 at 01:12, Jonas Maebe wrote:
> Except if you want to use the constant in another constant expression (which
> is not possible with a function, inlined or not).
Which, by the way, is another limitation that would be good to lift:
const PI = Arctan(1) * 4;
--
Alexander S. Kl
Thank you for the advice.
That works then. I can build against gtk1 or gtk2.
I have this problem then: The GTK2 canvas is very slow compared to GTK1.
I'm busy doing more work to add debug data to see where the slowdown takes
place.
If anyone has advice in the meantime, please let me know
On Mo
You could try the Qt widgetset too.
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Hello Vinzent,
Monday, October 19, 2009, 1:59:06 PM, you wrote:
VH> Of course, as you state, the visibility provided by the unit
VH> might be enough. But it also means, that a derived class may need
VH> to include that unit whereas in case of a class constant, it
VH> wouldn't need to. Not that th
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
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!
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
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
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
63 matches
Mail list logo
