오픈 소스 프로젝트 - XE 개발 포럼
글수 255
$GLOBALS나 Context를 거쳐서 static member 변수를 흉내내는 것을 대신하기 위해, Pseudo Static Member 클래스를 만들어 보았습니다.
PSM.php
<?php
$PSM_var = array();
class PSM // Pseudo Static Member
{
function getCallerClass()
{
$trace = debug_backtrace();
if(!isset($trace[2]))
return null;
if(empty($trace[2]['class']))
return null;
return strtolower($trace[2]['class']);
}
function &v($name)
{
global $PSM_var;
$class = PSM::getCallerClass();
if(!$class) // Caller is a global function
$class = '__global';
if(!isset($PSM_var[$class][$name]))
$PSM_var[$class][$name] = null;
return $PSM_var[$class][$name];
}
function &vc($class, $name)
{
global $PSM_var;
$class = strtolower($class);
if(!isset($PSM_var[$class][$name]))
$PSM_var[$class][$name] = null;
return $PSM_var[$class][$name];
}
}
class TestClass
{
function someFunc()
{
$someStatic = &PSM::v('someStatic'); // use it like TestClass::$someStatic
if($someStatic === null) $someStatic = 3; // initialize
++ $someStatic;
}
}
$obj = new TestClass();
$obj->someFunc();
$TestClassSomeStatic = &PSM::vc('TestClass', 'someStatic');
echo $TestClassSomeStatic;
$TestClassSomeStatic = 7;
?>
이런 식으로 static member 변수를 흉내내는 class를 만들어 $GLOBALS나 Context 사용을 대체하는 것도 좋은 기법이 될 것 같습니다.
2008.06.10 09:30:56 (*.8.18.250)
r4260 커밋하신것에서 제가 잘 못 생각하고 삽질을 했었네요.
함수단위의 static 변수가 php4에서 안된다고 생각하고 있었어요. 에고...
다시 4260으로 코드 돌려놨습니다. ^^;;;;
함수단위의 static 변수가 php4에서 안된다고 생각하고 있었어요. 에고...
다시 4260으로 코드 돌려놨습니다. ^^;;;;
2008.06.11 20:57:15 (*.37.65.47)
당장 몇 개월 내로 출시될 1.1.0의 경우 php4를 포기하기에는 무리이고, 이 다음의 b class 변경에서부터 포기하는 것이 옳을 것 같습니다. 사실 php 팀에서도 포기한 php4를 끼고 개발한다는 것이 많은 부조리를 부르지만, 아직 큰 문제는 나오지 않았다고 생각합니다.
그리고, __autoload 사용에 대해서 저는 부정적입니다. 보통 __autoload의 경우 여러 classes, modules, widgets등에 섞여 있는 파일 중 하나를 루프를 돌아 찾는 동작을 하기에, 성능에 대해 확신할 수 없게 됩니다. 더군다나 덩치가 큰 zbxe인 만큼, 더 큰 부작용을 부를 것으로 보입니다.
2008.06.11 22:12:12 (*.150.183.188)
네. 말씀하신 것처럼 1.2.0 이상의 버전에서 바꾸는게 더 나을 것 같네요.
그리고 __autoload의 경우 각 class 선언된 파일들이 약속된 네이밍으로 위치한다면 무리하게 루프를 돌지 않아도 됩니다.
일전 회사 사이트 제작시 매우 유용했던 기억이 나네요.
예를 들어 $a = new nameType(); 의 경우 name, Type등 클래스명을 이용하여 class file의 위치를 바로 찾아서 require 시킬 수 있어서 php에서 번거롭던 file require 하는 코드들이 필요 없게 되더군요.
뭐 이는 zbXE에서 getModule() 등의 함수를 이용하게 되면 큰 의미는 없게 되니 차후 필요하면 쓰면 될 듯 합니다. ^^
그리고 __autoload의 경우 각 class 선언된 파일들이 약속된 네이밍으로 위치한다면 무리하게 루프를 돌지 않아도 됩니다.
일전 회사 사이트 제작시 매우 유용했던 기억이 나네요.
예를 들어 $a = new nameType(); 의 경우 name, Type등 클래스명을 이용하여 class file의 위치를 바로 찾아서 require 시킬 수 있어서 php에서 번거롭던 file require 하는 코드들이 필요 없게 되더군요.
뭐 이는 zbXE에서 getModule() 등의 함수를 이용하게 되면 큰 의미는 없게 되니 차후 필요하면 쓰면 될 듯 합니다. ^^




작성해주신 PSM 코드를 이용해서 차후 구현할 애드온 기능 확장등에 사용하면 좋을 것 같네요. ^^
그리고 다른 이야기이지만, 현재 zbXE의 경우 php4 호환을 유지하기 위해서 GLOBALS 변수등을 이용한 정적 멤버의 흉내를 내고 있는데 이런 것들이 php5 이상만 가능하게 한다면 사실 불필요해질 수도 있다고 보여집니다.
php5 이상만 가능하도록 리팩토링 하는 시점을 당기는 것에 대해서는 어떻게 생각들을 하시는지 궁금하네요.
php5가 OO 관점에서 부족한 부분이 분명 있지만 autoload등의 기능과 여러 지시자들이 추가되어 코드가 간결해지고 그에 따른 퍼포먼스 향상이 보장되는데 계속 php4와의 호환을 염두에 두어야 하는지 요즘 고민입니다. :[
ps. 더블어 php에서의 패턴등에 대해서도 좀 더 연구를 해보고 공부를 해봐야겠네요. :)