Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TComponent has no constructor- All sub-classes should call parent::__construct in their constructor #339

Closed
ctrlaltca opened this issue Sep 14, 2013 · 12 comments

Comments

@ctrlaltca
Copy link
Member

From google...@pcforum.hu on June 25, 2011 07:53:45

The TComponent in the current trunk has no constructor, thus descendant classes can't call parent::__construct() to preserve a proper constructor chain, regardless of actual inheritance hierarchy. This is bad practice.

Also TPageNotFoundEventParameter tries to call parent::__construct() in its own constructor, but since neither its direct parent (TEventParameter), nor the latter's parent (TComponent) define any, it fails with a PHP error. Triggered when you try to open a non-existing page.

Original issue: http://code.google.com/p/prado3/issues/detail?id=338

@ctrlaltca
Copy link
Member Author

From ctrlal...@gmail.com on June 25, 2011 03:03:06

I've currently removed the offending __construct calls to fix the error, but maybe this topic needs some more discussion to ensure a proper decision is taken.
So if you're pro or against the introduction of a __construct hierarchy, please comment.

IMHO:
adding a lot of empty constructor calls is quite useless; it can help you to ensure that you won't miss to call a parent implementation, but it introduces a lot of unnecessary overhead. Then, what about a __destruct() hierarchy too?
In reality prefer the c++ approach, where you're forced to have a constructor/destructor and the parent::* calls are automatically executed; but this is php, and it's designed to work in a different way.

@ctrlaltca
Copy link
Member Author

From ctrlal...@gmail.com on June 25, 2011 03:19:31

Side note: in ticket http://code.google.com/p/prado3/source/detail?r=2990 javalizard points out a good reason why prado could need a constructor chain.

@ctrlaltca
Copy link
Member Author

From javalizard@gmail.com on June 25, 2011 09:04:16

http://code.google.com/p/prado3/issues/detail?id=257 TComponent doesn't have anything in it's constructor yet. These changes to chain the constructor/destructor are in place to enable my next set of check ins. The next TComponent checkin requires proper constructor/destructor chaining... it is also proper code form.

If something important were to be place in the TComponent constructor, like I'm going to be doing very shortly, these seemingly useless functions suddenly become very useful.

@ctrlaltca
Copy link
Member Author

From google...@pcforum.hu on March 10, 2012 17:03:32

I don't think the empty constructors would really add much overhead, since Prado's using now cached templates, configuration files, etc., which means that the overwhelming majority of objects used during the page cycle are now recontructed (save for the first time the template/page is referred) from serialized() strings by a call to unserialize(). The latter however does not call the constructors when re-creating the objects, therefore any overhead inside the constructors won't really affect Prado's performance - except for the first pageview and for dynamically constructed object at run-time.

An in-tact constructor chain however is key for proper and easy refactoring of both core and 3rd party/extension code, ie. where you can simply change the parent/base class of a derived object to add functionality to it or change it's behaviour, without having to worry whether the parent class has a constructor and/or that it gets called properly - because you can and do always call it in derived classes.

@ctrlaltca
Copy link
Member Author

From ctrlal...@gmail.com on June 25, 2012 06:56:52

Labels: -Milestone-3.2a Milestone-3.2.1

@ctrlaltca
Copy link
Member Author

From javalizard@gmail.com on November 07, 2012 10:56:13

r3211 This adds a common constructor function to TComponent. All classes with __construct need to call "parent::__construct"

Summary: TComponent has no constructor- All sub-classes should call parent::__construct in their constructor
Status: Accepted

@ctrlaltca
Copy link
Member Author

From ctrlal...@gmail.com on January 21, 2013 11:03:11

Labels: -Milestone-3.2.1 Milestone-3.2.2

@ctrlaltca
Copy link
Member Author

From ctrlal...@gmail.com on July 24, 2013 06:46:58

Labels: -Milestone-3.2.2 Milestone-3.2.3

@javalizard
Copy link

The milestone that the Behaviors are released within TComponent, all classes with __construct need to call their parent constructor.

I'm running into issues with Class Behaviors not attaching to new template objects. This is one of the use cases for class behaviors in that behaviors may be attached before classes are instanced.

Priority-Critical

@belisoful
Copy link
Member

I am unifying the __construct methods. There are many objects that wouldn't get their autoGlobalListen. Testing this is a real pain, but it's happening.

@belisoful
Copy link
Member

With these commits, this issue can be put to rest.

@ctrlaltca
Copy link
Member Author

Fixed in #746

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants