i wonder if there is any difference between
class TestClass {
private $_var = "abc";
}
vs
class TestClass {
private $_var;
function __construct() {
$this->_var = "abc";
}
}
i wonder if the latter is the preferred way/better practice? is there any functional difference?
They're effectively the same. I prefer the former, because then there's only one place to look for the value and its default.
On the other hand, if you need to do something dynamic with it or set it to anything other than an array or primitive, you need to use the second form. Notably, you can't use a function call to declare a variable in the first form.
Excellent question! I feel like the first example is more correct, if you already know the initial value of the object's attribute, why would you want to declare it in the constructor?
I feel like the purpose of the constructor is to set attributes that may be variable.
If anything, it seems like a readability thing. I don't know of any performance issues with either method.
I am not aware of any differences in your examples, they both seem to behave the same. if you do both, constructor code overrides the initialization done in the declaration section.
Personally I come from C++ background and in statically typed languages all declarations happen inside the body of the class but outside of any functions, and all initializations and other class prep happen inside the constructor.
When initialization is done as in your first example and there is some code doing something in constructor as well, to me it looks like mixing coding paradigms, so even though it is more verbose, I tend to pick your second example for my own style of code.
Related
I would like to believe that I understand the concept of static/early binding vs late/dynamic binding as well as late static binding but I found some conflicting definitions after reading few articles about it.
From my understanding the following:
<?php
class A {
protected $greeting = 'Hello from A';
public function hello() {
echo $this->greeting;
}
}
$obj = new A();
$obj->hello();
is an example of static or early binding which happens at compile time (even though PHP is interpreted language). It is early binding because all information about the class is known & nothing needs to be dynamically figured out, so class & method binding happens at compile time.
Dynamic binding or also known as late binding happens at runtime where class & method binding happens at runtime. If we take the same example as above but use something like inheritance, that would be late or dynamic binding:
<?php
class B extends A {
protected $greeting = 'Hello from B';
}
$obj = new B();
$obj->hello();
so my question is, is my assumption/understanding of static/dynamic binding correct in PHP? I know there is also late static binding which combines static & late binding and makes static properties & methods work with inheritance, so instead of using self:: you would use static:: which would wait for runtime to do the binding.
For reference, these are the articles I've read after having doubts about my own understanding of this concept:
This article states that
Static binding happens when you use the scope resolution operator ::.
but per my understanding that is not always the case, isn't my example above the one without inheritance a version of static binding as well? Static in terms of binding does not necessarily mean static variables.
The following articles are the ones with conflicting information, so this is why I am kind of confused & want to know whether I understand it correctly & if my examples are correct or not. I could not find the original RFC on PHP to get more insight as to how exactly this works.
https://www.codeproject.com/Articles/853792/A-Walk-Through-Into-Late-Static-Binding-in-PHP
https://joshduck.com/blog/2010/03/19/exploring-phps-static-scoping/
https://blog.julien-maury.dev/en/php-late-static-binding/
Which one of these articles is more on point as to how binding really works in PHP?
... is an example of static or early binding which happens at compile time (even though PHP is interpreted language).
You've managed to fit quite a lot of confusion into one sentence here.
Firstly, PHP is a compiled language, it is just compiled "on demand", into a high-level intermediate representation. What's more relevant is that PHP is a highly dynamic language, which doesn't do very much analysis during compilation.
Secondly, the example code you show could be optimised to a known method at compile-time, but it might not be. As far as the language is concerned, the statement $obj->hello(); is evaluated at run-time based on the current value of $obj. The fact that you can see the class to use on the line above, and know that that class has no parents, doesn't mean the compiler will definitely know those things and compile the code differently.
Thirdly, "early" and "static" can't just be used as synonyms - otherwise, the term "late static binding" would mean "late early binding", and make no sense. A "static" call is one that references a particular class; a "non-static" call is one which references an instance.
The important difference from the user's point of view is that given these three lines of code:
$someObject->methodOne();
self::methodTwo();
static::methodThree();
The definition of methodOne used will be whichever class $someObject is an instance of at the time that code runs. It might be a different method each time the line of code runs, if $someObject has a different value. This is late binding.
It will also reference the specific instance in $someObject, placing it in the magic variable $this. It is a non-static call.
The definition of methodTwo used will be the one in the class where that line of code is written. Every time that line of code runs, it will reference the same class. This is early binding.
The definition of methodThree used will depend on how the code was called - if it was called with the name of a child class with its own version of methodThree, that version will be used. Like methodOne, the line might run a different method each time. This is late binding.
Both methodTwo and methodThree will only reference a class, not an instance. They will not populate the magic variable $this. They are static calls.
yes your understanding is correct, because after creating class B and extending it from A, there two different versions of function hello(), which one is called at runtime depends on the type of object(A or B - to be determined by the context) calling it. Another way to look at it is that it is polymorphism.
For my latest website I’ve been trying to use classes. Mainly to teach myself more about OOP and learn through experience.
Whenever I needed a ‘variable’ within my class I created a property, for instance:
class someClass
{
var $valueToUseHere; // Only used internally - can I just use a variable?
public function doStuff()
{
$this->valueToUseHere = 60;
// Do more stuff here...
}
}
It is only now when I’ve been looking more into the code and trying to do some optimisation that I’ve noticed that my functions and classes are passing around some large objects. A lot of that bulk could be stripped away if I made all the properties that are only used inside the class into normal variables.
Are properties only used for variables that are needed outside the class and is it then acceptable to just use ‘normal’ variables within the class itself ?
Sorry if this question illustrates a lack of understanding on the subject. Unfortunately, this is where my learning is up to at this point. I’ve done some searching around “class properties vs variables” etc but not found a comprehensive answer to this.
Many thanks
It's somewhat vague what you're asking, but if valueToUseHere is not used outside of doStuff, then don't make it a property!
class someClass {
public function doStuff() {
$valueToUseHere = 60;
// Do more stuff here...
}
}
If there's no reason to share that value with other methods of the class or with the outside world, then there's no reason to clutter up your object with all sorts of properties. Not only may this cause tricky bugs with preserved state, it also forces you to be unnecessarily careful with your variable names across all object methods.
Actually class properties are variables as well. Basically you have three options:
Global variable, available everywhere, but not recommended because all parts of your code may depend on such a varialbe, changes can easily break stuff everywhere.
Class property (Note: you should define a visibility - public/protected/private) these properties are bound to the object instance and should be used for any state that the object needs to keep for further processing. Usually those might be used in more than one metohd of your class.
Variables inside a method like just
public function doStuff()
{
$valueToUseHere = 60;
// Do more stuff here...
}
The variable is just available inside the method and is thrown away at the end of the method execution.
That depends on your needs. If you are going to simply hold a value in a variable it's the best to keep it's simplicity and not define functions for setting or getting it's value. But sometimes you may need to have more controls on a variable in your class. For example you have defined an integer variable and you want it's values to be always between 10 and 1000 and also it should not be in 100,200,300,..,900. So here there is a good reason to set your variable access to private and create a public function to check what is required before setting a new value. Or in another example you may want to call another function or change another depended variable in your class exactly after this variable changed. Or if you want to make a variable read-only or write-only always you can define properties for controlling the variable value.
In brief you may prefer to use:
Properties: When you want to have control about get and set values
Variables: When you want to set or use a variable as its nature
My question is very simple, I saw this code in a class:
class controller_activity {
function __construct($args) {
//the variable template is not defined or what happen??
$this->template = new Template('activity');
}
.......
Usually I see the declaration of variables in a class like "public $template" or similar, but this case, is the same that if I define those variables as usual?, can I add variables in this way directly?, without defining them before?, is it recomendable?
is the same that if I define those variables as usual?,
No, the definition is missing. get_object_vars will show them, but get_class_vars won't.
can I add variables in this way directly?,
Yes, that is possible. They will be publicly visible.
without defining them before?,
Yes, without defining them before. They will be publicly visible.
is it recomendable?
That depends. Normally not, but there are exceptions to this rule.
I think the reason why this code works is because the $this->template assignment is happening in the __construct() which happens pretty much immediately on class instantiation. So this could be seen as a sloppy—but fudgable—way of doing variable assignment. But it doesn’t help for readability or debugging later on. So the answer is yes, you can do this. Is it a "best practice?" 100% no.
While not recommended, PHP and it's non-constraining (weakly typed) use of variables means that it is possible to declare class vars on the fly.
I've done it by accident on a number of occasions, but then gone back and defined them properly. By default they will have the public access method (the same behavior as not including an access method at the head of the class, i.e. $var = 0 versus private $var = 0).
Again, this is not recommended. I haven't tested for it specifically, but I would imagine that they throw a Notice error. The other issue is that doing this makes code harder to follow, either for yourself later on or another developer trying to work with your class.
The code you posted will work without a problem.
In PHP you can use undeclared variables. In other languages (like Java), you can't use undeclared variables. It's simply a matter of style, but I personally don't like using them.
Note that the template var, if undeclared as in your example, has public visibility
Basic setup. I have a classA instance which is a subclass of classX ... On construction (or sometime else), I want it to load another class classB which is also a subclass of classX and replace itself with classB in situ. Sort of like a factory, but one that replaces itself transparently. If need be, I can wrap classB with classA if there is a way to (at runtime) change the subclass of an object.
Currently I am using classA::__call() to emulate MRO magic, but is seems very inelegant. This needs to be done transparently to the caller of classA/B so that to the outside world, it isn't aware that classA has replaced itself with classB after construction (or anywhere else for that matter).
I know PHP can be a bit thin when doing things like this ... I am suspecting we can't, but it would be handy for my situation.
Also, 5.3 but ideally (yuck) 5.2/x
Thanks in advance (wishing I was coding in Python)
Ok, I've taken an interest in this question because I've reached the point where I'd like to discover the exact limits of PHP, including little hacks like this. Hopefully, I'll make sense this late at night and a few beers in me. Because of the ugly hackishness, I'm actually expecting to be downvoted.
Obviously, you can't do $this = $that. You also can't change the global variable you're currently trying to make into an object while it's being constructed, and attempting to do so will be ignored. As Charles said earlier, this can't be reasonably done. Not with clone, not serialize(), nothing within __construct().
So, unreasonably if you want $a to first become an object of class A, then convert mid-creation to class B, try this pseudo method: You'll have to call __construct of class A twice in a row. First time to handle construction of class A. Second time to complete the object converting it to class B. Class A handles the first half of construction, and class B the second half:
class A {
function __construct() {
$args = func_get_args(); // just to tell us the first round of __construct already occured
if (array_key_exists(0, $args) AND $args[0]) {
$GLOBALS['a'] = new B($GLOBALS['a']);
// stop because "reconstruction" has stopped. Nothing else you can do to $a in this scope.
$this->aprop2 = "yay";
// Seriously, stop. Don't bother putting more code at this point, you're wasting your time. Consider $a 'converted and returned' already.
}
// build on an object of class a here
}
}
class B {
function __construct($var) {
// maybe you'd like to do something with old $a? If so, here's $var for you
// continue constructing where A left off.
}
}
$a = new A(); // object of class A
$a->__construct(true); // object of class B
Maybe instead make another method of class A named more importantly sounding, which does the same thing to convert the global $a into object of class B, just so it doesn't look so stupid as my example. In other words, you're probably already doing it as best as PHP allows.
Edit: Really though, the above is nothing more than $a = new A(); $a = new B($a);. For better code readability and maintainability, you may want not to use my example and instead opt to implement a factory or handler class that creates and juggles these objects for you. I found a brief and insightful www.ibm.com article explaining the concept of factories how they are applied in PHP. Maybe conceptually, you want a static class that acts like a cd changer, and this is where Return by Reference - to work with a variable reference to the object in any scope - and Variable Objects (ref: midir's comments on that page) - to dynamically set or work with the object - comes in handy.
This is not currently possible in PHP...
Without doing stupid things.
If every instance of the object is a reference, and those references can be found in $GLOBALS, and the object knows what every one of those instances is called, you could replace each and every reference of the old object with your new object. The outside world won't know the difference.
This is, however, a spectacularly awful idea. Using __call magic is probably the least insane way of accomplishing your goal.
Edit: There's always runkit, which will let you do things like add and remove methods from classes. However, it's a PECL extension and might not even work correctly...
I am wondering if php methods are ever defined outside of the class body as they are often done in C++. I realise this question is the same as Defining class methods in PHP . But I believe his original question had 'declare' instead of 'define' so all the answers seem a bit inappropriate.
Update:
Probably my idea of define and declare were flawed. But by define outside of the class body, i meant something equivalent to the C++
class CRectangle {
int x, y;
public:
void set_values (int,int);
int area () {return (x*y);}
};
void CRectangle::set_values (int a, int b) {
x = a;
y = b;
}
All the examples of php code have the the code inside the class body like a C++ inlined function. Even if there would be no functional difference between the two in PHP, its just a question of style.
Here is a terrible, ugly, hack that should never be used. But, you asked for it!
class Bar {
function __call($name, $args) {
call_user_func_array(sprintf('%s_%s', get_class($this), $name), array_merge(array($this), $args));
}
}
function Bar_foo($this) {
echo sprintf("Simulating %s::foo\n", get_class($this));
}
$bar = new Bar();
$bar->foo();
What have I done? Anyway, to add new methods, just prefix them with the name of the class and an underscore. The first argument to the function is a reference to $this.
I stumbled upon this question while looking for a way to separate declaration and implementation of class methods. Why? For the sake of code readability. When the declarations are in a separate file, or at the top of the class file, someone looking to use the class does not have to wade through the whole implementation to find out which methods are offered.
I did find something useful though: PHP interface classes. I don't think they are designed for it, but they serve the purpose: an interface class defines all the methods, and then the "real" class implements them. Here's an article about it:
http://www.davegardner.me.uk/blog/2010/11/21/why-you-should-always-use-php-interfaces/
Having the declaration of methods in header files separate from their implementation is, to my knowledge, pretty unique to C/C++. All other languages I know don't have it at all, or only in limited form (such as interfaces in Java and C#)
It's possible, but very, very hacky and not recommended. No reason to do it either.
First of all, in PHP, all class methods must be defined and implemented within the class structure (class x { }). It is in no way like C++ where you have the implementations (*.cpp) separate from the definitions (*.h).
Natively PHP doesn't support features like this, but since PHP5.4 you can dynamically add methods to object. As an example, you can look at this: https://github.com/ptrofimov/jslikeobject
No. You can consider 'declare' and 'define' to be interchangeable in that question.