Well I, personallyOriginally Posted by devbanana
, don't like confusing operators and methods -- unless they are one and the same as it is in Smalltalk. In PHP they're not, and they won't be as long as there are primitives in the language.
| SitePoint Sponsor |
Well I, personally
Transparency. With operator overloading, you never know what kind of side effects may arise from something as simple as $a = $b + $c ... behind the curtain, it may trigger a whole chain of events, hitting the database or calling a web api to sell your computer on e-bay. You just can't tell by looking at the code.
We don't want to call any web APIs to sell my computer on e-bay.
In all seriousness, that's a risk in any language implementing this feature, but that's the developer's fault for not making those operators do what is intuitive. If you subtract two dates, I would expect to get a time range. If you add two dates, I'd expect to get a third date. It's a feature I've made good use of in C# and C++.
But that is exactly how it works in PHP. Only not when you add objects; instead, you can use unix timestamps to represent dates in PHP.If you add two dates, I'd expect to get a third date. It's a feature I've made good use of in C# and C++.
Maybe that's because $a, $b, $c don't have any semantical meanining? Assuming a compentent programmer who uses reasonable variable names, what do you think about overloading then?$a = $b + $c ... behind the curtain, it may trigger a whole chain of events, hitting the database or calling a web api to sell your computer on e-bay. You just can't tell by looking at the code.
Best.
You're right, and that's a viable argument. But assuming that programmers are competent is rather dangerous.
I'm not sure what I think about it, but I know that it's often held up as a problem of C++. (Then again - some see it as a great feature of C++)
The real problem with it is that it's transparent, which makes the code a lot harder to understand. It has impact not only where it's used, but also where it's not used.
Maybe I'm showing my Novice side here, but there's nothing stopping you doing anything you have mentioned here (apart from operator overloading) .. the 'real' question I am getting from all this is "Why can't php.net write this class for me?"
Sorry if that seems harsh, it's not intended
I wrote myself an arrayobject class a while back (and later - post php upgrades - had several applications die because I chose the name ArrayObject) which did exactly what you ask. I'll try and find it and post if you like, but after only a short while of using it.. I realised it just wasn't necessary and I was just being plain old fussy when it comes to how my code looks.
$array->itemExists('val') instead of in_array('val', $array) (and likewise for other array_* funcs).. is it really that necessary of a difference to warrant creating a whole class and potentially dozens of objects for? I finally answered that question with "No"
Your answer may differ of course
I know, but that was an example. There are other such instances where it could be used quite nicely with objects.
Quite true. But what would it hurt for the feature to be there? If programmers are going to write bad code, they're going to write bad code if operator overloading exists or not.
How's it have impact where it's not used? If you don't use the operator, then it doesn't use that feature.
I really don't think that's the case. I am a bit disappointed that PHP5's ArrayObject class doesn't include more. It's like they were going to include more, but didn't. If you look at the SPL classes, ArrayObject has a few sort methods, plus the normal array functionality for getting and setting items, but nothing else. In any case, it really doesn't matter, as it wouldn't be hard to write one.Maybe I'm showing my Novice side here, but there's nothing stopping you doing anything you have mentioned here (apart from operator overloading) .. the 'real' question I am getting from all this is "Why can't php.net write this class for me?"
Sorry if that seems harsh, it's not intended
I guess it depends on what you want to do. For me, I think it is worth it. Not to mention I want to make a few other data structures such as a few types of trees, etc. To each his own, though.I wrote myself an arrayobject class a while back (and later - post php upgrades - had several applications die because I chose the name ArrayObject
$array->itemExists('val') instead of in_array('val', $array) (and likewise for other array_* funcs).. is it really that necessary of a difference to warrant creating a whole class and potentially dozens of objects for? I finally answered that question with "No"
Your answer may differ of course
Indeed, I certainly can see where you are coming from - as I've already admitted I even had my own version!
It certainly appears PHP decided to separate their SPL classes into as concise a class as they can be, as such they really do have the bare minimum in ArrayObject (amongst others.) On a side note I believe this to be a big plus point for classes/objects in general.
But to touch a bit further on that, the other reason I stopped using my array-object class was simply because of the weight it carried. Having every array object hold methods for sort, diff, intersect, keys, values etc. etc. etc. just seemed overkill for scenarios where all I need is a stack, or a plain old data container. I did look at chopping the class into sub-classes, firstly by separating the iterator functionality, then 'specialist' array functions (diff, intersect etc.) and soon found my self with a whole lib full of tiny classes, which when put in code all take on more lines than just typing out good old fashion array_* functions.
All the above occured before the SPL included ArrayObject.
Actually, in this particular case I would simply use the __isset and __get overload methods, so when you try $array->val you'd just get a regular undefined index value with a null return.
I don't blame PHP for doing this. They have to make their classes work for all situations those classes would be needed in.Indeed, I certainly can see where you are coming from - as I've already admitted I even had my own version!
It certainly appears PHP decided to separate their SPL classes into as concise a class as they can be, as such they really do have the bare minimum in ArrayObject (amongst others.) On a side note I believe this to be a big plus point for classes/objects in general.
I also see where you are coming from. For myself, I do plan to have separate stack and queue classes with minimal functionality; just push, pop, peek for stack and enqueue, dequeue and peek for queue. The array class itself (whatever it may be called) would have the normal array functionality with all the various methods.
The thing is, I don't see what it matters if the class does have those methods regardless of what you want to do. I don't think it should add much overhead, should it? You don't have to use those methods; they are just there if needed.
I don't know, call me nuts, but it just feels cleaner to have an array object. I'm more convinced now that other people are saying they want to do the same thing, and now that PHP5 even has an array object.
Posting Permissions
Bookmarks