The Shed is going Social! Join us on FaceBook and Twitter and chime in on the conversation.
|
 |
|
Dev Shed Forums
> Programming Languages - More
> Delphi Programming
|
Object creation in Implementation section...
Discuss Object creation in Implementation section... in the Delphi Programming forum on Dev Shed. Object creation in Implementation section... Delphi Programming forum discussing Delphi related topics including Kylix, C++ Builder, and more. Delphi is a high-performance language, originally based on the PASCAL language.
|
|
 |
|
|
|
|

Dev Shed Forums Sponsor:
|
|
|

December 10th, 2012, 07:29 AM
|
|
Registered User
|
|
Join Date: Jul 2012
Posts: 28
Time spent in forums: 10 h 52 m 57 sec
Reputation Power: 0
|
|
|
Object creation in Implementation section...
Interface
Uses
Type
TSample = class (TObject)
end
Implementation
Uses
Type
TSample1 = Class (TSample)
end
I just need to access an object which is in implementation section of an object, is it possible ?
What's the use of this kind of object creation ?
Can we access this class(TSample1) from another class ?
|

December 10th, 2012, 09:24 AM
|
|
Contributing User
|
|
Join Date: Jun 2008
Posts: 254
 
Time spent in forums: 2 Days 23 h 55 m 14 sec
Reputation Power: 5
|
|
I've never seen where you declare a TYPE in the implementation section of a unit. Sorry for the pun, but the implementation section implements the code using the types you declared in the interface section:
Code:
unit Unit1;
interface
uses
...;
type
TSample = class (TObject)
private
privatevar: vartype;
...
procedure privateProc1(myparam: paramtype);
..
public
publicvar: vartype;
...
procedure publicProc1(myparam: paramtype);
end;
//you'd have to implement all of TSample's methods in Implementation section also.
//assuming TSample is part of Form1
TForm1 = class(TForm)
//all your form's objects and methods
procedure FormCreate(Sender: TObject);
//You can create a TSample in FormCreate...
procedure FormClose(Sender: TObject);
//Destroy TSample in FormClose...
private
//Declare an instance of TSample Here
MySample: TSample;
public
{ Public declarations }
end;
implementation
{$R *.DFM}
{TSample}//TSample Methods are implemented
procedure TSample.privateProc1(myparam: paramtype);
begin
//implementation of TSample methods
end;
procedure TSample.publicProc1(myparam: paramtype);
begin
//implementation of TSample methods
end;
{TForm1}//TForm Code implmentation
procedure TForm1.FormCreate(Sender: TObject);
begin
MySample := TSample.Create(nil);
end;
procedure TForm1.FormClose(Sender: TObject);
begin
MySample.Free;
MySample := nil;
end;
end.
|

December 11th, 2012, 01:04 AM
|
|
Contributing User
|
|
Join Date: May 2012
Posts: 140
Time spent in forums: 1 Day 4 h 53 m 15 sec
Reputation Power: 2
|
|
Quote: | Originally Posted by Murugavel Interface
Uses
Type
TSample = class (TObject)
end
Implementation
Uses
Type
TSample1 = Class (TSample)
end
I just need to access an object which is in implementation section of an object, is it possible ?
|
Yes, it is possible. In fact I have done it quite often.
Quote: | What's the use of this kind of object creation ? |
To make the class "private" to the unit. So the class is not accessible from outside the unit.
Quote: | Can we access this class(TSample1) from another class ? |
Only from code inside the same unit and after the "private" class declaration.
Final note: except for hiding the class from another unit I haven't found practical use of this approach. However from OOP point of view this is a good practice. Personally I done this only to avoid the "private" classes to show in Code Completion menu.
|

December 14th, 2012, 06:56 AM
|
|
Registered User
|
|
Join Date: Jul 2012
Posts: 28
Time spent in forums: 10 h 52 m 57 sec
Reputation Power: 0
|
|
Quote: | Originally Posted by Luthfi Yes, it is possible. In fact I have done it quite often.
To make the class "private" to the unit. So the class is not accessible from outside the unit.
Only from code inside the same unit and after the "private" class declaration.
Final note: except for hiding the class from another unit I haven't found practical use of this approach. However from OOP point of view this is a good practice. Personally I done this only to avoid the "private" classes to show in Code Completion menu. |
Thanks a lot,
I changed the access control, right now its available to other classes.
|

December 14th, 2012, 12:17 PM
|
|
Contributing User
|
|
Join Date: Jan 2006
Location: Carlsbad, CA
|
|
Quote: | Final note: except for hiding the class from another unit I haven't found practical use of this approach. |
Another, dangerous but sometimes useful, reason is to gain access to the protected section of the ancestor class.
|

December 14th, 2012, 12:28 PM
|
|
Contributing User
|
|
Join Date: May 2012
Posts: 140
Time spent in forums: 1 Day 4 h 53 m 15 sec
Reputation Power: 2
|
|
Quote: | Originally Posted by clivew Another, dangerous but sometimes useful, reason is to gain access to the protected section of the ancestor class. |
You talked about "cracker" class. Unfortunately, if you read prior posts carefully you will see that we did not discuss about that.
|

December 16th, 2012, 01:53 PM
|
|
Contributing User
|
|
Join Date: Jan 2006
Location: Carlsbad, CA
|
|
Quote: | You talked about "cracker" class. Unfortunately, if you read prior posts carefully you will see that we did not discuss about that. |
Hi Luthfi,
Sometimes I have difficulty understanding your responses.
When I simply reply to your comment that you have never found any other use for declaring an object type in the implementation section with another possibility why on earth would you respond by chastising me for not reading the prior posts?
It was you, after all, who introduced the idea that there were no other uses.
Having followed your posts and links for some time, I respect both your knowledge of Delphi and your willingness to share and help. I just get surprised by the acerbic nature of some of your responses to me.
|

December 16th, 2012, 11:37 PM
|
|
Contributing User
|
|
Join Date: May 2012
Posts: 140
Time spent in forums: 1 Day 4 h 53 m 15 sec
Reputation Power: 2
|
|
Quote: | Originally Posted by clivew Hi Luthfi,
Sometimes I have difficulty understanding your responses.
When I simply reply to your comment that you have never found any other use for declaring an object type in the implementation section with another possibility why on earth would you respond by chastising me for not reading the prior posts?
It was you, after all, who introduced the idea that there were no other uses.
Having followed your posts and links for some time, I respect both your knowledge of Delphi and your willingness to share and help. I just get surprised by the acerbic nature of some of your responses to me. |
I think you just never tried to understand my posts. You talked about cracker class which does not necessarily to be declared in implementation of a unit. So the purpose of that cracker class does not specifically tied with the advantage of declaring class in implementation of a unit.
Cracker class got its "benefits" from the fact that protected section is visible from descendant class(es).
When I said I found no other uses I talked about all kind of classes in general. Not cracker class, which (again) does not have to be declared in implementation.
Is that so hard to understand?
Last edited by Luthfi : December 16th, 2012 at 11:43 PM.
|

December 17th, 2012, 01:02 PM
|
|
Contributing User
|
|
Join Date: Jan 2006
Location: Carlsbad, CA
|
|
Quote: | Is that so hard to understand? |
What is hard to understand is your acerbic attitude.
It is a fairly well known approach to hide a cracker class in the implementation section of the unit in which it is required rather than making it visible to the entire application.
In that respect I believe it was a legitimate observation in response to your comment about the limited uses of declaring an object type in the implementation section. Certainly not deserving of your derogatory suggestion that I should read the prior posts more carefully.
Anyway - enough of this. Either your attitude will mellow or it will not.
Let us turn to more productive conversations.
|

December 18th, 2012, 04:39 AM
|
|
Contributing User
|
|
Join Date: May 2012
Posts: 140
Time spent in forums: 1 Day 4 h 53 m 15 sec
Reputation Power: 2
|
|
Quote: | Originally Posted by clivew What is hard to understand is your acerbic attitude. |
I don't see why do you feel so bitter about my attitude. Or was it your ego? Why don't you just answer the simple questions, and prove that cracker class must be declared in implementation section? If you can then I admit my mistake and apologize. If you can't, please don't pretend that the problem is my attitude.
Btw, I now seem to recall that you could never answer direct simple technical questions when the answers would disappointed you. I think you should work on that too.
Quote: |
It is a fairly well known approach to hide a cracker class in the implementation section of the unit in which it is required rather than making it visible to the entire application. |
Your response simply confirms my point. Declaring cracker class in implementation IS FOR HIDING. NOT A NECESSITY.
Quote: |
In that respect I believe it was a legitimate observation in response to your comment about the limited uses of declaring an object type in the implementation section. Certainly not deserving of your derogatory suggestion that I should read the prior posts more carefully. |
Then it's also a legitimate response that cracker class is not what we were talking here. BECAUSE IT DOES NOT NEED TO BE DECLARED IN IMPLEMENTATION SECTION.
Quote: Anyway - enough of this. Either your attitude will mellow or it will not.
Let us turn to more productive conversations. |
Like I have said before, I don't care about you.
Last edited by Luthfi : December 18th, 2012 at 04:42 AM.
|
Developer Shed Advertisers and Affiliates
| Thread Tools |
Search this Thread |
|
|
|
| Display Modes |
Rate This Thread |
Linear Mode
|
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
|
|