Nie jest to jakoś szczególnie problematyczne ale nie umiem zrozumieć dlaczego tak jest. Kod:

[PHP] pobierz, plaintext 
class jakakolwiek {
 
	function __construct() {
 
		$nazwaZmiennej = '_POST';
		$$nazwaZmiennej = array('test' => 'test nr 1');
		var_dump( $_POST );
 
		$_POST = array('test2' => 'test nr 2');
		var_dump( $_POST );		
 
	}
 
}
 
$jakakolwiek = new jakakolwiek();
[PHP] pobierz, plaintext 

Powyższy kod wyświetli jedynie drugi fragment - tj. pierwszy var_dump wskaże, że $_POST jest puste.
Dlaczego tak się dzieje i dlaczego ten problem występuje wyłącznie w ciele klasy? Jeżeli napiszemy to poza klasą to działa zgodnie z założeniem.

Na ten problem natrafiłem gdy chciałem w aplikacji MVC przekazać do widoku zmienną _POST.
Bez MVC po prostu stosowałem $_POST = mysql_fetch_assoc(mysql_query(...
które w prosty sposób pobierało wartości domyślne do inputów (kod był poniżej update).

Wychodzi na to, że mamy dwie zmienne - lokalną $_POST i superglobalną $_POST.

[PHP] pobierz, plaintext 
class jakakolwiek {
	function __construct() {
		$nazwaZmiennej = '_POST';
		${$nazwaZmiennej} = array('test' => 'test nr 1');
 
		$_POST = array('test2' => 'test nr 2');
	}
}
 
$j = new jakakolwiek();
var_dump(get_defined_vars());
[PHP] pobierz, plaintext 

Ale nie wiem czemu tak

Minuta googlowania: http://www.php.net/manual/en/language.vari...uperglobals.php

"Note: Variable variables
Superglobals cannot be used as variable variables inside functions or class methods. "

Ok, dzięki.

Teraz pytanie jak to obejść i jakoś w widoku nadpisać ten POST.
Ostatecznie zrobię oddzielną tablicę $default ale nie każdy formularz buduje za pomocą klasy i zawsze to więcej kodu..

Szczerze mówiąc nie rozumiem twojego problemu. Czemu zamiast:

[PHP] pobierz, plaintext 
$nazwaZmiennej = '_POST';
$$nazwaZmiennej = array('test' => 'test nr 1');
var_dump( $_POST );
[PHP] pobierz, plaintext 

nie zrobisz po prostu:

[PHP] pobierz, plaintext 
$_POST = array('test' => 'test nr 1');
var_dump( $_POST );
[PHP] pobierz, plaintext 

ewentualnie, każdy element posta sprawdzić, czy jest i jak nie ma to wtedy dopisać wartość domyślną.

Normalnie bym tak zrobił ale w MVC wartości do widoku przekazuje w taki sposób:
$this->registry->template->_POST.

A czemu w ogóle chcesz nadpisywać?

Wyjaśniłem w drugiej części pierwszego postu.

W widoku nadpisać POST... Hm... jak już to złe miejsce na takie rzeczy.
Po 2, przekazuj tablic a nie działaj na gołej zmiennej superglobalnej w klasie, kiedyś będziesz chciał coś zmienić na GET, będziesz musiał zmieniać wszystkie wystąpienia POST, nawet w prostym IDE to nie problem ale jak dla mnie tak się robić po prostu nie powinno.

[PHP] pobierz, plaintext 
$ret = Forms::valid($_POST, array(
  'foo' => 1, // lista defaultowych zmiennych
  'bar' => 2
));
$this->view->assign('formValues', $ret);
[PHP] pobierz, plaintext 

W żadnym wypadku nie chciałem tego robić w widoku.
Często mniej jednak kusi aby to zrobić z kontrolerze (zapytanie SQL).

Przyglądam się Twojego przykładowi i chyba rozumiem.
Metoda valid zwraca dane z POST, a w przypadku ich braku (nie wysłany formularz) dane defaultowe.
Potem w widoku w inputach <?= $formValues['name']; ?>.
W sumie to od początku było to moją alternatywną opcją tylko po prostu:

[PHP] pobierz, plaintext 
<?php
if (!isset($_POST['submit']))
 $ret = array('pole' => 'wartosc_domyslna');
else
 $res = $_POST;
// $res do widoku.
[PHP] pobierz, plaintext 

Normalną praktyką jest używanie requesta, który zawiera żądania POST, GET, zmienne serwerowe itp. itd. etc.
Dostęp do tego w kontrolerze np. taki:

[PHP] pobierz, plaintext 
$request = $this->getRequest();
[PHP] pobierz, plaintext 

Teraz możesz zmienną nadpisać/ustawić używając np. metody setParam. Jest to na pewno wygodniejsze niż korzystanie z "gołych" superglobalnych tablic.

Ma to jakieś zalety ale czy to jest bezpieczne?
Jak dobrze rozumiem z kilku tablic generowana jest jedna.
Co jeżeli w POST i GET i mamy taki sam indeks?
Co gorsza tablicą SERVER możemy manipulować przez GET np. http_referer=XYZ.

Kwestia ustalenia ważności, np. post nadpisuje get ale już nie server, nie widzę też problemu by wyłączyć możliwość nadpisywania niekórych zmiennych nawet z wewnątrz kontrolera przy użyciu ->setParam, można też zmienne grupować albo inaczej obsługiwać nadpisywanie zmiennych.

Dodatkowo taki obiekt request wyposażamy w inne przydatne metody typu ->isPost czy np. sprawdzenie czy żądanie jest wysyłane ajaxem.

Wygodne to bo grupuje nam zmienne superglobalne i powiązane z nimi metody w jednym miejscu - a jak to okodujemy w szczegółach to już zależy od nas.

A miałoby sens set/get Param z drugim argumentem, który np. byłby defaultowo 'POST' i określałby do której tablicy się odwołujemy?

isPost to po prostu alias dla if($_POST) czy coś głębszego?

Z tego co wiem isPost() sprawdza po prostu, czy została wysłana tablica post i zwraca true albo false.

W np. Zend Frameworku drugi parametr to defaultowa wartość zmiennej, coś w stylu:

[PHP] pobierz, plaintext 
$variable = $request->getParam('name','Zdzichu'); //jak nie przekazaliśmy nigdzie zmiennej "name" to domyślnie będzie to "Zdzichu" ;)
[PHP] pobierz, plaintext 

Natomiast ja to widzę bardziej tak:

[PHP] pobierz, plaintext 
$name = $request->getPost()->name;
$name = $request->getPost()->getParam('name');
[PHP] pobierz, plaintext 

Zależy, jak okodujemy.