I made a typo, in D4 these constructs are valid. So what are the changes in the compiler.
I guess accessing protected or private memebers of classes defined in the same unit is stil valid, but not if they are originally defined in another unit ???

Marc

This is code which compiles under D4 ! (if you want an example I'll give one)

Marc

+ From: Michael A. Hess
+
+ Marc Weustink wrote:
+ >
+ > This is code which compiles under D4 ! (if you want an example I'll
+ > give one)
+
+ I give up. I must admit you are correct. Not believing it myself I wrote
+ a test program in Delphi 4 and by god you are correct. To me that
+ doesn't comply with the definition of private, protected and published
+ but it does work and the current code in TDesigner should be OK if it is

Pffeeew ;-)
I have to admit that the first time I saw it I was shocked. This behaviour is IMHO against the object model; private members should be realy private, and not visible in the unit. The same for protected.

+ Sorry about giving you a hard time Marc. I truly believed what the
+ Delphi documentation said and I have always coded that way
+ and had never even attempted to do what TDesigner did because I
+ just thought you couldn't.

Same here, I "discovered" this feature while I started working on the internals of Lazarus, on how and when a component is created.

Marc

This interpretation is correct and seems to be compatible with Delphi

The behavior of protected was fixed the last days, so maybe it still doesn't work 100%.

Peter, can you have please a look a it, because you stated in the sources:
{ check protected and private members }
{ please leave this code as it is, }
{ it has now the same behaviaor as TP/Delphi }

Marc Weustink wrote

This is code which compiles under D4 ! (if you want an example I'll give one)

I give up. I must admit you are correct. Not believing it myself I wrote a test program in Delphi 4 and by god you are correct. To me that doesn't comply with the definition of private, protected and published but it does work and the current code in TDesigner should be OK if it is to be Delphi compatible. My investigation found the following:

Private - Visible in the unit declared by any class or method found in that unit.

Protected - Same as Private plus. It is visible by any class or method in other units if a class in that unit is a descendent of the original class. In other words if a class in a given unit is a descendent of a class in another unit then all of the protected members of the original class are now visible in this descendents unit.

public - Visible anywhere by anybody.

Since TDesigner is defined in the same unit "Forms" as TCustomForm which is a descendent of TControl then all public and protected members should be visible within the "Forms" unit. If TDesigner was defined in a different unit then TCustomForm then only the public members would be available to TDesigner.

So FPC guys it appears that the current private, protected, public layout matches the documentations definition but it doesn't match the current operation of Delphi.

Sorry about giving you a hard time Marc. I truly believed what the Delphi documentation said and I have always coded that way and had never even attempted to do what TDesigner did because I just thought you couldn't.

No that isn't correct (see below)

If protected is the same as private (only more visible) then also counts that protected members are visible outside the class, which seems not the case now.

No that is the case.

What is causing the problem is the method trying to access

     FCustomControl.IsControl;

The FCustomerControl variable is defined in the TDesigner class found in the Forms unit.

FCustomControl is defined as

FCustomControl = TCustomForm

TCustomForm is also defined in and part of the Forms unit.

However TCustomForm is a deriviative of TWinControl

TCustomForm - class (TWinControl)

This is defined in and part of the Controls unit.

Then in the controls unit TWinControl comes from TControl which is where the method IsControl is actually defined as "protected".

You are attempting to access a protected unit in a class from a different unit. If you note the definition of protected says that,

"members of a Protected section are also accessible to descendent types, even if they are implemented in other modules"

In this case TCustomForm can access it's own protected member even though it is located in a different unit BUT TDesigner which is not a descendent can't access a protected member of TCustomForm which it inherited from a different unit.

Got that. :-)

If TDesigner and TCustomForm where located in the controls unit then this would work fine. In this case a public member is required in the TCustomForm class to allow TDesigner access.

Marc Weustink wrote

Since TCustomForm.IsControl is a protected member of TCustomForm it can be accessed.

Correct. TCustomForm can access the protected member. This means that TCustomForm can access the protected member from inside one of its OWN methods. Ex:

procedure TCustomForm.Something;
begin
if IsControl
{
.
.
}
end;

That the protected member isn't declared in TCustomForm is another point, but it is still a protected member. The doc's don't say where the member should be declared.

Sure they do. The docs say, "members of a Protected section are also accessible to descendent types, even if they are implemented in other modules". In other words protected members in a class are available outside of a unit if the class is a descendent. If it isn't a descendent then the member is visible in the unit.

Besides that this is how Delphi implemented it, so it should be possible in de delphi mode (I couldn't check it since we have other problems in delphi mode).

No I'm afraid not. The definition as indicated in the FPC docs and the way it is working is exactly the way Delphi defines it and how Delphi works. Following is the definition as it is found in the Delphi 4 documentation. The wording is different but it says the same thing.

=================================
A private member is invisible outside of the unit or program where its class is declared. In other words, a private method cannot be called from another module, and a private field or property cannot be read or written to from another module. By placing related class declarations in the same module, you can give the classes access to one another�s private members without making those members more widely accessible.

A protected member is visible anywhere in the module where its class is declared and from any descendant class, regardless of the module where the descendant class appears. In other words, a protected method can be called, and a protected field or property read or written to, from the definition of any method belonging to a class that descends from the one where the protected member is declared. Members that are intended for use only in the implementation of derived classes are usually protected.

A public member is visible wherever its class can be referenced.

==================================================

Note the last line of protected. "Members that are intended for use only in the implementation of derived classes are usually protected." It can only be used implementation of derived classes not from another class that happens to be defined in the same unit.

Or we have to declare thing more public, or we heve to put units together. I don't like both of them.

You just need to declare a property in the TCustomForm unit as public that accesses the IsControl member. You do not need to modify the TControl
==== Programming my first best destiny! ====

Michael A. Hess Miracle Concepts, Inc.
http://www.miraclec.com

Marc Weustink wrote

I guess accessing protected or private members of classes defined in the same unit is stil valid, but not if they are originally defined in another unit ???

As defined in our wonderful FPC documentation. ;-)

Private - All fields and methods that are in a private block, can only be accessed in the module (i.e. unit) that contains the class definition. They can be accessed from inside the classes� methods or from outside them (e.g. from other classes� methods)

Protected - Is the same as Private, except that the members of a Protected section are also accessible to descendent types, even if they are implemented in other modules.

Public - sections are always accessible.

Published - Is the same as a Public section, but the compiler generates also type information that is needed for automatic streaming of these classes. Fields defined in a published section must be of class type. Array peroperties cannot be in a published section.

+ From: Michael A. Hess

[snip]

+ You are attempting to access a protected unit in a class from a
+ different unit. If you note the definition of protected says that, +
+ "members of a Protected section are also accessible to descendent
+ types, even if they are implemented in other modules" +
+ In this case TCustomForm can access it's own protected member even
+ though it is located in a different unit BUT TDesigner which is not a
+ descendent can't access a protected member of TCustomForm which it
+ inherited from a different unit.
+
+ Got that. :-)

Yes, this is how it is implemented now, but if you look at he docs another interpertation is possible. It says:
1) protected is the same as private (with a more visible scope)

2) private members can only be accessed in the module (i.e. unit) that contains the class definition.
They can be accessed from inside the classes' methods or from outside them (e.g. from other classes' methods)

So 2) also counts for protected. I read this as

3) protected members can only be accessed in the module (i.e. unit) that contains the class definition or the module (i.e. unit) containig the descendent definition.
They can be accessed from inside the classes' methods or from outside them (e.g. from other classes' methods)

Since TCustomForm.IsControl is a protected member of TCustomForm it can be accessed. That the protected member isn't declared in TCustomForm is another point, but it is still a protected member. The doc's don't say where the member should be declared. Besides that this is how Delphi implemented it, so it should be possible in de delphi mode (I couldn't check it since we have other problems in delphi mode).

+ If TDesigner and TCustomForm where located in the controls unit then
+ this would work fine. In this case a public member is required in the
+ TCustomForm class to allow TDesigner access.

Or we have to declare thing more public, or we heve to put units together. I don't like both of them.

Marc

Then I don't understand where the compiler is complaining about, since the protected member we are accessing is a member of a class which is defined in the same module.
If protected is the same as private (only more visible) then also counts that protected members are visible outside the class, which seems not the case now.

I have to admit, this is a somewhat strange behaviour whithin the object model, but IMHO it is something what should be controlled by some kind of switch.
<pessimistic>
If not we might end up with all units together in one big unit. </pessimistic>

Marc