Nathan Rixham schreef:
> Afternoon all,
>
> I'd love to get some votes from my fellow developers on the following,
> and indeed some opinions (especially from those who disagree).
>
> Recently I've been running in to a lot of frustrations with PHP when
> dealing with Classes and Objects. Personally I strongly feel that these
> need added in to PHP 6, for multiple reasons.
>
> I don't think the scope of this discussion covers the syntax of any
> implementation, just if it needs implemented or not.
>
> a: Optional Static Typing
> I'm finding an ever increasingly need to be able to staticly type
> properties, parameters, return types etc (in classes) I know there is
> type hinting but it's just not enough to do what one needs. Additionally
> support for staticly typing primatives. Here's an example:
>
> <?php
> class Example {
>
> private ClassName $obj; // class typed property
an object should know and be able to control what goes into a
private property - no need to type it.
>
> public bool $primativeBool; // primative typed property
don't really see much use in public properties on the whole,
of an object is supposed to be self-sufficient blackboxy in nature
have the innards hanging out is rather counter-productive.
-1
>
> // typed returns
> public function getObj() ClassName {
> return $this->obj;
> }
>
this would only be useful if your doing some really heavy meta-programming, which
essentially means shed-loads of reflection. not exactly performant in php.
besides how does the engine uphlod such a contract, it would be a beast performance
wise to track each and every returned value from each call of such a method if it's
even possible ... and then what happens if something other than ClassName was returned?
do we get a fatal error as we do with typehinted parameters? that wouldn't
really help in terms of graceful error handling.
> // already implemented
> public function setObj(ClassName $obj) {
> $this->obj = $obj;
> }
I don't see much use for this given the fatal error you get if you pass in
the wrong thing, some code does benefit by being able to contract this stuff
and fix any mistakes at development time ... I use it sometimes.
> // privative type hint (not implemented)
> public function setPrimativeBool(bool $primativeBool) {
> $this->primativeBool = $primativeBool;
> }
doesn't really buy me anything. I'm merely offloading the responsibility
of casting paramter $X to the calling code rather than have the method just
deal with whatever it's given. this increases the developer burden and
the amount of code needed when using said method. I'd rather just do
something like:
class Foo {
function setBool($bVal) {
if (!is_bool($bVal) && !is_numeric($bVal)
throw new InputException("your sh** stinks!");
$this->myBool = (bool)$bVal;
}
}
> public function someMethod() {
> // also for variables
> VariableType $variable = new VariableType();
> }
this is nuts, they're zvals under the hood. if your code is so unclear
and unmaintainable that you can't manage to track/control a variable inside
a single method then something else is wrong.
again what happens when I stick something different in $variable, do
I get a fatal error ... not very helpful ... especially given the
interpreted nature of the language.
-1
-1
-1
> }
> ?>
>
> b: Object superclass
> A base class type which all objects automagically extend, with (if
> nothing else) a unique id / hashcode for each object (much like the Java
> Object class). Failing this some form of function to get a unique
> reference string for any variable. Example
http://php.net/manual/en/function.spl-object-hash.php
>
> <?php
> $someClassInstance = new SomeClass();
> // method on all objects that returns a unique
> // id for that object
> $objectId = $someClassInstance->hashCode();
>
> // or by a function
> $objectId = get_hashcode($someClassInstance);
> // and for variables
> $aString = 'some string';
> $stringId = get_hashcode($aString);
> ?>
I don't understand why you would need this. given that variables
only exist within the current scope such an id would be useless beyond
request boundaries. sharing [serialized] data between requests, users and/or
machines requires a somewhat more refined strategy (e.g. see how memcache
is used)
>
> c: Method overloading
> TBH it's something I could live without, whereas a/b aren't, but it
> would be an ideal addition to php?
>
> <?php
> class Example {
>
> public function someMethod(ClassType $arg0) {
>
> }
>
> public function someMethod(ClassType $arg0, bool $arg1) {
>
> }
-1
> }
> ?>
>
> Thoughts, Opinions, Votes? would love to hear from you guys on this
pretty much all of the above are adhoc wishes that are not well thought
out, with regard to functionality details or BC (the devil is in the details,
case in point being the namespace implementation ... if you followed it's
development you knoe about that ... I think your suggestion are much more
far reaching that namespaces).
php is dynamically typed it's counter intuitive to try and force it to behave in a
statically typed manner. maybe a new compiled language using php syntax as basis
could do such things and if it was all implemented consistly then maybe it
would fly, but I don't think the php ecosystem is capable of supporting the
introduction of such stuff.
I guess it kind of comes down to 'use java' if that's what you prefer,
either way there is a snowballs chance in hell of this lot getting any serious
attention from php devs.
that lot was JMHO, no offence intended Nate :-).
> Regards!
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
