I just read the recent documentation and found some undocumented features, such as slice, strict, and dispinterface. Can anyone explain what they are? And are there any more than these 3?

I just read the recent documentation and found some undocumented features, such as slice, strict, and dispinterface. Can anyone explain what they are? And are there any more than these 3?

AFAIK, "slice" is delphi comatibility function. Here's the description: http://delphi.about.com/library/rtl/blrtlSlice.htm

"dispinterface", it also delphi compatiblity reserved name to define a dispatch-interface used with Windows COM.

"slice" and "dispinterface" have been there long time ago.

"strict" is introduced for new delphi compatibility? http://delphi.about.com/od/delphifornet/a/aa022404a_2.htm [quote]
any member of a class (variable, method, property, ...) has a visibility attribute. In addition to "standard" Delphi visibility specifiers, Delphi for .Net adds two new access specifiers. Again, when you start a new FCL Windows Forms application, and look in the code that defines the main Form, you'll see two new "groups": strict private and strict protected.

A member of a class declared with the strict private visibility is accessible only within the class in which it is declared - not visible to procedures or functions declared within the same unit.

A member of a class declared with the strict protected visibility is accessible within the class in which it is declared, and within any descendant class.

Here's an example:

~~~~~~~~~~~~~~~~~~~~~~~~~
type
   TWinForm = class(System.Windows.Forms.Form)
   strict private
     Components: System.ComponentModel.Container;
     DataGrid1: System.Windows.Forms.DataGrid;
     procedure InitializeComponent;
     procedure TWinForm_Load(sender: System.Object; e: System.EventArgs) ;
   strict protected
     procedure Dispose(Disposing: Boolean) ; override;
   public
     constructor Create;
   end;
~~~~~~~~~~~~~~~~~~~~~~~~~
[/quote]

thanks,
dmitry

Hi guys,

"strict" is introduced for new delphi compatibility?

A most welcome addition.

I'm ashamed to admit that I only found out that it's been included in FPC today. I ran an old VM which has FPC ver 2.2.2 installed, and "strict" is supported! I'm currenly using FPC 2.2.5

What other "jewels" are hidden from "view"? Is there some documentation documenting undocummented features that one can read?

As for compatibility with later releases of Delphi (2007 - 2009 etc), how far is FPC going to go? While I don't know whether the FPC team envisage the FPC comiler morphing into FPC for .NET, there are some compiler/language feature specific to .Net that I wouldn't mind having included in FPC. Some features like sealed classes, class constants, class variables, static constructors and destructors, to name a few. Are there plans to implement such features in FPC?

I would think that some of the above feature had to be introduced into .Net because a (close to) pure OO impementation does not support global vars, global functions etc. as a hybrid language like Object Pascal does.

Regards to all,
Nino

What other "jewels" are hidden from "view"? Is there some documentation documenting undocummented features that one can read?

That's sort of a contradictio in terminis :) I'm not aware of a list of "still to be documented features" either. It's best to file bug reports against the documentation when you encounter such omissions.

As for compatibility with later releases of Delphi (2007 - 2009 etc), how far is FPC going to go?

Delphi 2009-style generic/unicode string support is planned, but other than that there are no fixed plans at this time afaik.

While I don't know whether the FPC team envisage the FPC comiler morphing into FPC for .NET,

Unlikely, although a .NET code generator could always be added at one point.

No concreate ones. They can always be added if someone is interested in doing the work and maintaining them, of course.

Jonas

In our previous episode, said:

I would think that some of the above feature had to be introduced into .Net because a (close to) pure OO impementation does not support global vars, global functions etc. as a hybrid language like Object Pascal does.

Java and C#/CLR are usually considered as not pure OO. Pure OO doesn't know value types. I think most of these were just about scoring bullets on the comparison list with C#, except "strict var".

Questions about private visibility have appeared regularly in forums for years, usually comparing with other languages. I think codegear was simply tired of the debate and implemented "strict *", for people that want to micromanage visibility (*)

Afaik Florian did some of the easier later constructs, but be careful, some might not be complete (only parsed). I recall something of the class var/const etc also working.

There is to my knowledge no real roadmap, since these things are not driven by roadmap, but by need. Somebody who wants them spends time on them etc. Probably the slow progress is because none of these are particularly exciting, and nearly all public codebases and components are D7 backwards compatible and thus don't contain these.

(*) something which is IMHO not proper OO, which is about modelling not
about finegrained permission models. What's next, classtypes with ACLs ? :-)