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 not allow to call a contructor of such a class. I have found QC report regards this but anyway parser supports them.
Sealed class is a class which can't be derived by another class. This one is fully supported by delphi.

Using attached to this report
http://bugs.freepascal.org/view.php?id=14824 patch I achieved the same behavior by fpc. But as I wrote - it is my first patch and I know nothing about compiler developement rules. Please review and comment if something is wrong.

Best regards,
Paul Ishenin.

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 will see a nice progress ;-) I too know next to nothing about FPC internals, so I have only a generic comments:

1) (Not your fault, but) the patch is unnecessarily big due to msgidx.inc and msgtxt.inc changes -- why these generated files are under version control at all?
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 warning.
Also, this code would be hard to extend in case some more options are needed. I would suggest to trite it as a loop adding all options, and then after the loop check for conflicts:
if [oo_is_abstract, oo_is_sealed] *
current_objectdef.objectoptions = [oo_is_abstract, oo_is_sealed] then error;
Finally, I think the function should be named parse_class_options.
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?

Besides, I have some comments on the feature itself.

At moment 'class abstract' in delphi do nothing although it should not allow to call a contructor of such a class. I have found QC report regards this but anyway parser supports them.

I see little value in this feature apart from Delphi compatibility. Abstract classes are already identified by compiler by abstract methods. Currently, compiler gives a warning abut them, but I think that should actually be an error.
So, I would propose:
1) In Delphi mode, accept "abstract" keyword and warn about abstract methods.
2) In OBJFPC mode, do not accept "abstract" keyword and change warning to error.

Sealed class is a class which can't be derived by another class. This one is fully supported by delphi.

Sealed classes is rather controversial feature, see e.g. http://www.sellsbrothers.com/news/showTopic.aspx?ixTopic=411 http://weblogs.asp.net/cazzu/archive/2005/08/29/IHateSealed.aspx .. and many other similar ramblings.
Also note that the original paper on sealing classes (in Java) http://www.haifa.ibm.com/info/ple/papers/class.pdf introduces slightly different semantics:
"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.
So, I would propose, in OBJFPC mode,
to allow inheriting from sealed class in the same unit

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 are supposed to do and thus - don't know how to implement them. Obviously this also means, they are placeholders for something which I don't need right at the moment.

Forcing the programmer to implement such, when he doesn't even know what for, is definitely more annoying than a warning.

As an example, there are/were "Open" and "Close" methods in TXHTMLDocument, which I finally implemented with a null-method just to get rid of the warnings when instantiating descendants.

The missing documentation tells me - nothing. Of course. So I suppose, these methods are really very important and the whole program will fail if they are neither implemented nor called. :P

Vinzent.

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 in hell I can forsee every possible use of the classes I created. So why would I want to limit the usefulness of a class - it goes totally against the OOP principles.

Imagine the TList class was a sealed classes. We would never have been able to create a TObjectList, TInterfaceList, TStringList, etc... and reusing the basic implementation from TList to save time and code reuse.

Not to shoot down your efforts or anything, I just don't understand the point of a sealed class. It sounds more like something Microsoft would implement to stop developers from reusing their classes like "Outlook Bar" and extend it to something much better than the standard one included in MS Office.

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't see the point of sealed class. Why would you want to limit the use of a class. It goes against the OOP principals. One developer cannot think of all possible uses for a class, so why limit other developers that could see other uses or extensions.

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 from.

type
  TAbstractClass = class sealed
    procedure SomeProcedure;
end;
---------------------------

The class name suggests that it is an abstract class, meaning you cannot use the class as-is, you need to create a descendant so you can actually implement "SomeProcedure". Why else would they call the class "AbstractClass". But by the "sealed class" rules, you cannot create a descendant. So now you have a class you can do absolutely nothing with! :-)

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 I created. So why would I want to limit the usefulness of GG> a class - it goes totally against the OOP principles.

I think it has been designed to avoid derived classes from commercial packages.

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 Shell extensions (thousands)
* Nokia's Qt - extended to be called KDE
... the list goes on!

All these that I mentioned and many more, all meant the commercial package became more popular and more used. Isn't that what commercial entities want?

Graeme Geldenhuys пишет:

Sealing does not prevent reusing in form of aggregation (when the sealed class is a member of your own class). Wishing/forcing users to use aggregation instead of inheritance may be a valid point sometimes.

Imagine the TList class was a sealed classes. We would never have been able to create a TObjectList, TInterfaceList, TStringList, etc... and reusing the basic implementation from TList to save time and code reuse.

These cases use precisely aggregation, so, in fact, the code of TObjectList, etc. wouldn't change if TList was sealed.

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 member, this mechanism could be disrupted system-wide. 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...

Regards,
Sergei

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 sealed.

Yes some use aggregation, but some also use inheritance. In fact TObjectList *does* use inheritance - not aggregation. See class definitions below:

  TClassList = class(TList)
  ...
  end;
  TObjectList = class(TList)
  ...
  end;
  TComponentList = class(TObjectList)
  ...
  end;

Well, I did point out that the feature is controversial. You can read some arguments supporting sealed classes in the paper I cited. It should be noted that most compelling of these arguments are based on the fact that Java can enforce member access at runtime, so private members and sealed classes are useful as security devices.
Since FPC will never be able to do that, this use-case for sealed classes moot.

However, the paragraph you quoted was intended to illustrate very different use case
(see TBasicChartSeries class definition and documentation): prohibit the client code from inheriting base class, while allowing to inherit it's decendants.
I.e. in TAChart, we have this chain of inheritance: TBasicChartSeries -> TCustomChartSeries -> TChartSeries -> TBasicPointtSeries ->TLineSeries.
Of these, TBasicChartSeries and TBasicPointSeries classes are implementation details used to reduce code duplication, their interface subject to change without notice.
So it would be useful to explicitly prohibit inheriting them outside of TAChart code.
Of course, inheriting other classes should still be allowed.

So, how about this semantic (which nicely mirrors "private" access specifier): "sealed" class attribute prevents inheriting from sealed class by the classes outside of the unit containig that class.

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 member, this mechanism could be disrupted system-wide.

Yes, this is one ot the reasons. Another is that classes implementing class attributes are apparently very inefficient in CLR unless they are sealed. This, btw, might say that we should imlpement sealed for FPR value classes (aka type T = object ...)

But as soon as a feature appears, it starts to be used (and abused, too) here and there.

Agree, this is to me the strongest argument against sealed classes -- the feature _can_ be used correctly, but will be usually used wrongly by clueless
programmers.

Done with no warning/hints. I decided not to show warning since fpc allows to declare methods with many 'abstract'.

Ok.

Finally, I think the function should be named parse_class_options.

no, later it could be used for another types of objects.

Same with any other keywords. If we want to compile delphi projects then
we need to support delphi syntax.

Besides, I have some comments on the feature itself.

Feature was made to support delphi syntax and it do this in almost 100% compatible way. If there are some problems with this then I can modify the patch to allow this only in delphi mode.

Best regards,
Paul Ishenin.

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 (although a bit extended) for the Jonas objective pascal project.

Best regards,
Paul Ishenin.

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, they just provide a way to access private/protected class section.
Categories actually are adding methods to a obj-c class.

thanks,
dmitry

Please look at example here: http://edn.embarcadero.com/article/34324

TMyClassHelper there has added HelloWorld and MyFunc to the TMyClass type.

Best regards,
Paul Ishenin.

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 than class-helper declaration?

thanks,
dmitry

I am not sure but suppose they are not.

Can these helper methods be used in units other than class-helper declaration?

As I know you can use helper methods in other unit if that unit uses a unit with helper declaration.

Best regards,
Paul Ishenin.

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.

Graeme Geldenhuys :

Me neither. But there may be some use, still.

Why would you want to limit the use of a class. It goes against the OOP principals. One developer cannot think of all possible uses for a class, so why limit other developers that could see other uses or extensions.

Quite true. But you don't need "sealed" for that. It is enough to "forget" to declare some methods as "virtual". I don't remember how often I tried to extend some class (like TThread), finally realizing that some required method can't be overriden...

Vinzent.

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 "sealed" is just meant as hint to the compiler that the VMT remains static or something.

Vinzent.

It might be more but at least from compiler developer's point of view it can be used for this.

Well, yes. And from the programmer's PoV "inline" can be used as a restriction to prevent pointers to such functions. ;)

Vinzent.

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 the latter (the parent) you can still extend your hierarchy. Correct me if we are wrong ;)

We use it a lot after codereview and final checkin the production branches. For us it means: "you must have a very good reason to touch it"

Florian Klaempfl wrote on Sat, 17 Oct 2009:

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 life -- even doing it for an entire program using WPO generally has no noticeable effects on speed, and only marginal effects on code size).

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

So, what do you think about my version of sealed semantics for OBJFPC mode? I think the use case I described gives real, although admittedly very small, benefit, compared to no benefit (apart from compatibility) of Delphi semantics.

True. But sealed requires no recompilations to do the optimization, so it works always.

Florian Klaempfl wrote on Sun, 18 Oct 2009:

I made a mistake here: they can't improve it. Since such a class won't be derived from even without the "sealed" specifier, the compiler can perform all those optimizations automatically already.

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 people into using delegation rather than inheritance, and this in turn can cause problems if the sealed class is "unsealed" later on and new descendants are created after all (e.g., because they directly created a delegate of the "sealed" type since it couldn't be inherited from anyway).

Manually doing things that can be automated is almost never a good idea.

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

No. But I see it as a possibly usefull side effect of OOP access controll so being even more usefull than e.g. private and friends.

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 the C++ is compiled in a dll with C bindings and on the delphi side, a mirror hierarchy is created. This was the case with the qt3clx port some time ago. It actually looks quite elegant, and obviously, one cannot extend the functionality of the original Qt methods. So, even if one assumes that the VMT layout is the same, there are slight, but significant differences in the polymorphism semantics in Delphi/Java and C++. Therefore, aggregation is the only option.

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".

As for abuse of concepts - the richer a language becomes, the more paths to abuse it. no way around that.

Peter Popov

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 support it syntax. Delphi has "sealed". Why should we invent something uncompatible?

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).

As for the optimization angle, maybe it works for .BPLs. When compiling the BPL you can't know if the main program uses it.

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 always change the code. But even then they have a warning function.

But they do their security role very good when you distribute your code in the binray form.

Except the security role sealed and abstract classes have their important oop meaning. Look at the next "phones example":

TBasicPhone = class abstract
TCellularPhone = class(TBasicPhone)
TSatelitePhone = class(TBasicPhone)
TDialPhone = class(TBasicPhone)
...
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 final product which can't have any further derivations. It is logically to mark this class as sealed to prevent ocasional errors.

After all, nobody ask to use sealed/abstract classes as much as possible. If you don't like them - just don't use them. Why to limit other developers?

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.

After all, nobody ask to use sealed/abstract classes as much as possible. If you don't like them - just don't use them. Why to limit other developers?

Yeah I know. That is always the excuse for all extensions.

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:

That's the weakest motivation for a language feature that I ever saw. "comment for people that don't read comments) :-)

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.

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 languages nave
no such ability.

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 ;-)

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?

Best regards,
Paul Ishenin.

2009/10/19 Paul Ishenin :

Bad example! :-) 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 problems with the speaker. Revision 1.x (or 2.x - I don't know how they numbered them) have those hardware problems fixed. So it's the same model phone N5800XM, but it has various differences.

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!

Graeme Geldenhuys wrote

Bad example! :-)

Quality of this example varies according to the initial POV you have.

Very good. Try to include all that differenced into basic class.

Remember:

TAbstractPhone = class
public
   property Color: TColor;
end;
TNokiaPhone = class(...)
public
   property Revision: String;
end;

So you have a class of TNokiaN5800XM and you can get plenty of instances with your different revisions, colors, etc. Don't mix classes and instances.

Best regards,
Paul Ishenin.

Without discussing details, I think a singleton is a good example where sealed is useful.

This might be true, but what's the difference with private etc.?

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 or the class, on its own, is of no use whatsoever. (Having said that, one never knows what someone else can do with ones code.)

I have also encountered situations where I could have benefitted from extending the functionality of a class, only to find that it was sealed.

IMO, the sealed modifier was primarily designed to mark a class as sealed for commercial reasons, in order to prevent a third party from extending the class.

All features being equal, I would rather have class constants and class types included in FPC.

Regards,
Nino

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 to implement Singleton in Object Pascal. For years I have had a singleton implementation that you cannot create instances from, except one global function that return the very first (and only) instance.

So even without "sealed" support, Singleton is possible, but yes that is probably the best (and only) use I can see for 'sealed'. So adding a language feature for only one specific design pattern seems a bit over the top.

By I guess this whole thread got taken over by the "sealed" discussion. I'm pretty sure, through all this, Paul is still waiting on a definite answer of: is my patch ok?

Irrespective if developers should/shouldn't use 'sealed'? I guess that answer can only be decided by the developers preference to OOD & OOP. Just like there are many other language features in Object Pascal I will never use - "label & goto" come to mind. :)

After all there are a couple of reasons to add it
- Delphi compatibility
- at least the singleton pattern
- commercial packages
- possible optimization without wpo

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.

See
http://github.com/graemeg/freepascal/commit/6d0dc36b82ba90403594f00bdd96a36b5b820f66 ;)

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 sealed would hurt.

As I said, it's as usefull as private/protected/strict private/strict protected imo

I use hierarchies of singletons quite often, and having them sealed would hurt.

You can still/should seal the class instanciated?

Well, the problem is that sealed is class-global -- it is like having class with all members private -- totally useless. Now, "final" keyword that Paul also implemented in his branch is a much better feature
due to its finer granularity.

> I use hierarchies of singletons quite often, and having them sealed would hurt. > You can still/should seal the class instanciated?

Sorry, I can not understand this sentence.

Good enough for me. :-)

See http://github.com/graemeg/freepascal/commit/6d0dc36b82ba90403594f00bdd96a36b5b820f66 ;)

In that case... Congratulations Paul, on your first compiler contribution. :-)

Then simply don't use "sealed". Or use "sealed" on you last class definitions that will actually be instantiated. I'm now thinking of "sealed" like I do about "label..goto" and "+=" etc... It's available, but doesn't mean you need or must use it.

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.

Jonas

Modifiers are never keywords in Delphi.

Michael.

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.

Best regards,
Paul Ishenin.

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 constant value. Then, if you are a moron, you will have to write a lot of code to do a senseless thing, otherwise possibilities for abuse multiply exponentially :-)

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.

The implementation I'm talking about that would have a constant PI=3.1415 within say MyClass would only work if called as MyClass.PI

In your example, the global PI would always be defined unless somebody redifines it, and then it's not a class constant anyway.

if OOP is about data encapsulation, why are we using global constants and types?

Nino

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 something that comes with "modern" software - live with it. ;-)

In that case, an entry should be added at http://wiki.freepascal.org/User_Changes_Trunk

Jonas

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 Sealed/Abstract fields in the published sections without actually declaring "published".

Even if some exists there will be no mach.

Best regards,
Paul Ishenin.

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,
dmitry

Of course. Still, Jonas is right, this should be mentioned in wiki.

2009/10/19 Marco van de Voort :

But what if I can't understand the comment, because somebody wrote it in Russian? ;-)

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.

If you want to get all pros and contras please read the full thread.

If you want only aggregation, read this:
http://lists.freepascal.org/lists/fpc-devel/2009-October/017840.html

Best regards,
Paul Ishenin.

In _my_ opinion, the wiki should state that
"This feature is added only for Delphi compatibility. It may create problems for the users of your code. Please do not use it in new code."

But there are people with other opinions here ;-)

Paul Ishenin :

And what is with the TNokia3720Phone_DeluxeEdition which is basically the same as TNokia3720Phone, but with some enhanced features?

Why to limit other developers?

Precisely. ;)

Vinzent.

Paul Ishenin :

By written contract. As it is always done in the commercial sector. And no, I'm not talking Eiffel here.

Vinzent.

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.

In your example, the global PI would always be defined unless somebody redifines it, and then it's not a class constant anyway.

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.

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 different entities. I think that is more than enough, as far as constants are concerned. So, what the class constant really implements is an inline function, returning a fixed value. Thus, the mechanism is already there and providing a meaningless language expansion goes the C++ way: every programming paradigm can be done in several different ways. This confuses the inexperienced mind and leads to the above mentioned absurdities.

Peter

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: TNokia3720PhoneEdition;
end;

Best regards,
Paul Ishenin.

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 you encourage self-documenting source code or dislike the code-explorer's "unnamed const" count to go up, then you may want to use constants.

It would also indicate to someone using your library, that they could change the source and use a diff constant. (Hopefully without having to check for further occurrences of this value)

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

"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 finite computing machine.

So in fact, there may be more than one approximation, i.e. one for single-precision, one for double-precision.

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.

If the constant is used within the class and in descendants only, it might. I'm a strong believer of reduced visibility.

Of course, as you state, the visibility provided by the unit might be enough. But it also means, that a derived class may need to include that unit whereas in case of a class constant, it wouldn't need to. Not that this is a particularly strong argument. ;)

Vinzent.

And then inside the implementation:

TNokia3720Phone.SomeMethod;
begin
   case self.Edition of
      n3720peStandard:
         ImplementedThatWay;
      n3720peDeluxe:
         ImplementedThisWay;
   end;
end;

?

You really gotta be kidding me.

Vinzent.

Note that I only think that it's a bad idea to use this feature for optimization purposes (because it invites breaking the design of interfaces for no good reason: the performance improvements will be small and they can be achieved much better by automated means anyway). I have no strong opinion on it otherwise.

Jonas

Peter Popov пишет:

While this is true, it is also true that Pascal unit encapsulation level was introduced also long before objects/classes appeared in the very same Pascal. Today, classes serve as namespaces of their own, but these namespaces are limited in comparison with unit namespaces, because they can contain only methods, fields and properties.

Also, there are not only 'true' constants, but typed constants, too. I believe that nothing technically prevents using space of class VMT for storing not only method pointers, but other data as well.

Regards,
Sergei

This is your opinion, and you are entitled to it, however, as I have already said, class constants fit in better with OOP, where the constant has meaning only within the class that houses its definition.

According to your logic, the same could be said for global variables versus class fields.

When you are phone manufacturer you know you model line very well. So you can define final classes and intermediate very well. If implemenetation is different then you are free to use

TNokia3720PhoneStandard = class sealed(TNokia3720Phone) TNokia3720PhoneDeluxe = class sealed(TNokia3720Phone)

and ofcource in this case TNokia3720Phone becomes not sealed.

I don't want to continue this discussion. Moreover I don't ask anybody to use it if they find this not useful. Those who need it will use it. What's the problem after all?

Best regards,
Paul Ishenin.

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.

Well, if we're looking to add functionality I would think NameSpaces like in C# would be useful to bind constants and data structures to namespaces... Just my $0.02

Except if you want to use the constant in another constant expression (which is not possible with a function, inlined or not).

Jonas

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 bit (such as replacing the 'abd' with 'and' in the title :)

Jonas

This is a good example. However, the same paradigm can be achived by a function:

function TItemCache.DEFAULT_CACHE_SIZE: Integer;
begin
   Result := 1024;
end;

If properly inlined, the compiled code is the same and semantically the two are the same.
Granted, defining it as constant saves the 4 lines needed to implement the function :-)

In the same example, a typed global constant gives it a different flavour, in the sense that the user of the class can modify the value at run-time, e.g. by reading an ini file/registry entries when the app starts.

Peter

Here's someone who has taken some initiative and all we've done is shoot him down. Come on guys?

Nino:-

Paul Ishenin :

*coughcough* Have you ever worked in the industry? Implementing customer requirements?

You can do that. Of course. After shipping the final product. IOW: At a point where the software development for the product is finished, frozen and closed already.

I don't want to continue this discussion.

So be it.

Moreover I don't ask anybody to use it if they find this not useful. Those who need it will use it. What's the problem after all?

That it adds restrictions to the _users_ of the code without any compelling reason. IOW: It's not the developer of code who has to live with the restriction, but the user. Much like I hate that someone doesn't declare a method as "virtual" just because he didn't see any use for it.

Vinzent.

In our previous episode, Florian Klaempfl said:

Private is typically used in nearly every class, sealed in exceptional cases. At best.

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;

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 this is a particularly strong argument. VH> ;)

When writting generic classes (not generics) I usually had to write in fact 2 files:

MyUsefulclasses.pas and MyUsefulclasses_types.pas

Of course the information in the second file are "private" constants and types for the first file classes. A non exportable zone of the code at the beginning of the unit will solve most of this "problems", as private types and private consts are for a given class. In the spirit of pascal (from my point of view) would be more logical to have a private zone in the interface zone, specialy for types.

Just adding my 2 cents fo noise to the thread :)

also less flexible.

Florian Klaempfl :

The main difference is that "private" restricts visibility, whilst "sealed" restricts extensibility. The former is usually a good thing, the latter not.

Vinzent.

Zitat von Vinzent Höfler :

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 becomes more complex, newbies have more to learn, it allows to create dead end code and all this has to be maintained. That's all.
That's nothing.
It does not hurt.

Many a mickle makes a muckle.

Mattias

This is true for any language feature. If we continue to think so then maybe we return to the procedural programming since you can do anything you want only using procedures. Hmm... and you even don't need functions in the language since you already can use var arguments in the procedures. Oh... stop. What for we need procedures and arguments? We can write all we want even without procedures. Hey, and let's remove the string type. What for we need it if we can use the char array.

What we will get in the result of this language simplification? Yes, extremely fast and easy compiler but do you like it?

Best regards,
Paul Ishenin.

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 discussed about using class attributes.
Delphi has:
TMyHelper = class helper of TParent
...methods...

  end;

  TAbstractClass = abstract class(TSomething)
     ...methods...
  end;
  TSealedClass = sealed class(TSomething)
     ...methods...
  end;

but FPC can use
TMyHelper = class(TParent)
[helper]
...methods...

  end;

  TAbstractClass = class(TSomething)
    [abstract]
     ...methods...
  end;
  TSealedClass = class(TParent)
    [sealed]
     ...methods...
  end;

Using attributes makes language, simplier, because user don't need to learn new constructions, they might need to learn *possible* attribute, modifiers.
Let's say, thay FPC packages are finally implemented, and helper and sealed classes are supported. The final syntax of the class would be:

  TSealedClass = class(TParent)
    [sealed, external]
     ...methods...
  end;

With new features added to the FPC, will be easily added for classes: TMyCoolClass = class(TParent)
[feature1, feature2... etc]
...methods...

  end;

Such syntax also makes parsers' job easier. Because, they don't need to be aware of new structures, but treat anything inside '[..]' as set of modifiers or strings separated by commas.
"attributes" and "stringed attributes" are already used in Interfaces declaration:
IMyInterface = interface
['{2EC9224F-3D48-4CD3-80E7-2EF7441C0DD5}']

     procedure Method;
  end;

Of course the primary reason for adding new structures (helpers/abstract/sealed) to the compiler is delphi compatibility, they can be left for {$mode delphi} only.

thanks,
dmitry

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 even wanted to propose that myself, but it breaks compatibility.
I would like to defer the current sealed/abstract implementation to Delphi mode and use some general syntax for fpc/objfpc.

In our previous episode, dmitry boyarintsev said:

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.

It's not only not visible but neither accessible. And if something is not accessible, it affects flexibility.

There is a strange kind - from an academic point of view - of discussion going on here.
- one part is confusing language syntax with compiler optimizations
- another part is driven by not understanding why somebody invented sealed classes.
The first is or maybe a side effect.
The second should be understood to be restrictive on purpose, by design. I think a lot of people whom I highly regard are focussing in the wrong direction. Sealed has a purpose and a very good one: It prevents OO extensions by design, which is a good thing. see my example from two days ago. And, Marco, this is fully compliant with a true OOP philosofy ;) just my 2 c

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 sad, eventual Delphi syntax support makes FreePascal actually FreeDelphi.

About FPC syntax and new feature: fpc packages (afaik not yet implemented). I'm wondering, what syntax would be used to define an "external" class. Would it follow obj-p (objc branch) style? (adding 'external' keyword after class declaration).

thanks,
dmitry

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't measure FPC's identity on basis of the dialect alone. That is only a carte blanche for unbridled extensions.

About FPC syntax and new feature: fpc packages (afaik not yet implemented). I'm wondering, what syntax would be used to define an "external" class. Would it follow obj-p (objc branch) style? (adding 'external' keyword after class declaration).

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.

See http://wiki.freepascal.org/packages for some explanation.

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 why C is so flexible, it doesn't have all this visibility shit... ;)]

The feature is called "information hiding". The times of "every identifier is global" are over, I suppose?

Let me put it this way:

"private" can be misused sometimes.
"sealed" will be misused most of the times.

The use-cases for "sealed" given so far were quite debatable, I think.

Vinzent.

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 (without .pas files). 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.

thanks,
dmitry

In our previous episode, dmitry boyarintsev said:

Yes. Linking to such units is not fundamentally different from linking to other precompiled code. But on Delphi this is in .dcp packages. (since packages can also have static parts)

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 with dcu present, but no .pas files. Any type or routine present in dcu can be used. The only problem of using them, is that there's no information in human-readable form about what actually presents in dcu.

Most of commercial components use this strategy: They do not provide sources, but they provide compiled .dcus (for any delphi version). With .dcu files they provide documentation over the component, so the user can see what classes, methods, functions or types are available, without need of studying sources.

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.

No, this would cause completely unpredictable behaviour regarding whether or not a function can be used inside a const statement (since the compiler will never contain a full emulator that is able to interpret any arbitrary Pascal function).

Jonas

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

In our previous episode, dmitry boyarintsev said:

FPC also, but has .ppu/.o. (but harder to manage not giving source due a multitude of questions.

But that is not related to the "external" question. The point is that the .ppu have a defined state of a compilation step, with all the information needed for the COMPILER.

This is different from linking to C/Obj C or other external sources where you only have binary state after compiling the first part, enough for the LINKER.

No. .dcu is not a documentation format. The information is primarily for the compiler, and .ppu contains the complete state needed for the compiler to use that unit from another unit/prgram. Rougly Delphi .dcu folds in the actual object code (.o) together with the unit info (.ppu) into one file