Jenk
-
Posts
778 -
Joined
-
Last visited
Never
Posts posted by Jenk
-
-
My name is John, too. I win
-
E_NOTICE's:
[...] Indicate that the script encountered something that could indicate an error, but could also happen in the normal course of running a script.
Perhaps you could explain to me, sans E_NOTICE, how a variable which is unset is "a different case entirely from having a null value". Afterall null was invented in order to designate absence of value.
<?php $foo = null; if($foo === $bar){ // no E_NOTICE for $foo, only for $bar - Jenk 3 - Patrick 0. echo '$foo is equal to an undefined $bar'."\n"; } if(!isset($foo)){ echo '$foo IS set (to null)'."\n"; } ?>
Patrick - 1 Jenk - null :-p
...
Jenk 4 - Patrick 0.If a variable has been unset with unset()' date=' it will no longer be set. [b']isset() will return FALSE if testing a variable that has been set to NULL.[/b] Also note that a NULL byte ("\0") is not equivalent to the PHP NULL constant. -
Now turn on all errors and watch that "E_NOTICE undefined variable $bar" error message fly. Jenk 2 - Patrick 0.$HTTP_RAW_POST_DATA is not always set. A different case entirely from having a null value.
Hmm... you sure?
<?php $foo = null; if($foo === $bar){ echo 'Patrick - 1 Jenk - 0 '; } ?>
I think that PHP initializes all variables to null unless explicitly assigned a (non null) value.
Patrick
-
$HTTP_RAW_POST_DATA is not always set. A different case entirely from having a null value.
Also note it is a deprecated variable, look at using the $_SERVER global array instead.
-
var_dump it to see what's in it. I can tell you already, there is atleast one non-object in there.
-
list($low, $high) = explode('-', $string);
-
iirc it raises an E_NOTICE error when you don't declare the variables.so basically there is absolutely no point what so ever in declaring a instance variable public. and i realize why they are meant to be private its so you cant access it directly form the instance, correct ?
If you want to create a value object or similar, you can declare the __set() and __get() magic methods to store data cleanly.
<?php class ValueObject { private $_data = array(); public function __get ($name) { if (!isset($this->_data[$name])) throw new IndexOutOfBoundsException($name . ' is not a valid member'); return $this->_data[$name]; } public function __set ($name, $val) { $this->_data[$name] = $val; } } $foo = new ValueObject; $foo->bar = 'Hello Worls!'; try { echo $foo->bar; } catch (IndexOutOfBoundsException $e) { echo '$foo->bar has not been set yet!'; } ?>
-
PHP automatically creates a public instance variable, if you assign a value to that which does not exist.
-
I can't really tell what your requirements are from those snippets, but if SOAP is not your requirement (i.e. transactions) then why not just use SimpleXML and plain XML?
-
Why not SOAP?
also..
$this->string = $doc->getElementById($subset.$msgId).nodeValue;
Getting your syntaii mixed up?
-
You're trying to be insulting again. "Chill out", I'm not annoyed/angry. "Now don't get mad at me for telling it how I see it, there is not one right way unless you're a Christian and quoting the bible. Maybe you should be a little less caught up with OOD heuristics and start thinking for yourself." How utterly condescending of you.
The debate isn't purely about registry vs the rest; it's about globals vs the rest.
Data mapper or DAO - and infact every - object ever created only cares about the interface of another object. To extend your example of a user, dao and datamapper; none of them need to know anything about any object they relate to, other than if they fit the interface.
Node path's are no more than 3 or 4 deep, at the very worst. If your node path's extend further than 3 you should really consider redesigning as a rule of thumb. Some exceptions such as ORM examples do exist. If not a registry, then your controller should be instantiating objects and passing to the sub-components. Something like:
<?php class { public function run () { $this->_view = new View(); $this->_view->display(new Model()); } } ?>
is fine. Encapsulation is not broken; the View object does not know what the Model object is, except that it fits the expected interface. The controller is doing it's job, controlling which nodes are invoked.
and just adding this as I was typing the above whilst two more replies came in..
utexas_pjm.. yes, that's also a perfectly acceptable use of the registry.
"The point goes beyond the Domain Model. After posting that I realized that it was probably not the best example example of the problem. In fact, I was a bit disappointed in Jenk for not noticing and banging me down for it. " I refer you to my first comment.
-
Like I said, you have a fault in your design if that is the case. Why are objects calling on objects that don't need parameters, yet the object below them need parameters? Remove the middle man if that is the case.
You can be witty (and trying to be insulting) and draw all the pictures you want, singleton's cause problems. Encapsulation is broken with any form of global. Why use objects if you are not going to use their interface? Might as well go back to procedural programming.
-
Still solved by passing a registry instead..
<?php $registry = new Registry; // add stuff to $registry here $controller = new Controller($registry); // now within the controller.. public function doSomething() { // add more stuff to the registry here, before using the following $this->_child = new SomeChildClass($this->_registry) $this->_child->run(); } //now within the child.. public function run() { $this->_view = $this->_registry->at('view'); $this->_view->setModel($this->_registy->at('model')); $this->_view->display(); } ?>
crappy example, but explains the concept clearly.
-
If you're using a registry, you only ever need to pass around one object... the registry.
-
Registry does not need to be singleton.
Avoid singleton's. There are very few circumstances where one is warranted.
-
You've missed the point entirely.Daniel0: that works fine if I'm accessing $ifc0nfig->MySQL outside of a class, but if I'm in another class (navi) I cant access the MySQL object or even the ifc0nfig object (without class extends). The classes are in differant files (shouldn't matter?).
Jenk: Not sure if I follow you here but making $_mysql private isn't going to help at all? I want other classes to be able to access it.
1. The navi object is constructed outside of your ifc0nfig class, thus not breaking encapsulation.
2. It is not an extension, it is a parameter.
3. You are free to pass around the navi object to other objects.
-
There's no reason to extend one with the other in this case, they are not interrelated in such a way to make it viable. Instead, use the mysql/navi object for what it is, an object.
<?php class ifc0nfig // what's with the 0 instead of o? { private $_mysql; public function __construct (navi $db) { $this->_mysql = $db; } public function doSomethingWithMySQL() { $this->_mysql->doSomething(); } }
-
Have you "installed" the smarty library on the server?
-
You've already answered your own question..yeah i get you now but how would i make a script that would go through like that and then check that value against another until they match and echo out what is has tried??? im now just interested lol
-
You're asking about brute-force attacks, which of course are blatantly possible - so why even ask that question?but how come if you get the md5 from the database then md5 the users input and compare they would match so you cant just use a loop to go through?
and it's not possible to check if the nth character is correct, you must and can only compare the entire value.
-
Aimed at anyone who thinks 100kb of wasted memory is not a bad thing.
-
Learn to make use of unit tests and test driven design, then you can goodbye to debugging.
-
The object will be carrying all that 100kb of class data with it, whether you use it or not.
Would you take an 18 wheeler to collect your morning newspaper from the shop which is only 100m away?
-
100kb for a class?
Too big. Period.
OOP?
in Application Design
Posted