SitePoint Sponsor |
|
User Tag List
Results 26 to 50 of 79
-
Dec 2, 2005, 13:34 #26
Originally Posted by bonefry
that lines up with their constant kiss everything principle. well, keeping it simple for them anyways. To keep it easy on the user, the developer has to work harder or at least smarter.
I actually wish they would slow down some, the speed and lack of planning has really kicked in and they are at a cross roads with the language. a decent road map would be nice, not to mention, if they are going to break so much bc, then maybe they should take the time to make a very clean break. like uniform style, function parameters (needle, haystack comes to mind), and IMHO,
have clean classes instead of classes like File in the SPL. Thats nothing but a hacked class wrapper around file functions with a very C procedural like naming convention, not OOP. Not to mention, clean up and comment the code base. =).
-
Dec 2, 2005, 16:19 #27
- Join Date
- Oct 2004
- Location
- naperville
- Posts
- 189
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Will that fail us as well, much like the way the function library has?
-
Dec 5, 2005, 13:27 #28
Originally Posted by Super Phil
actually it is a prominent issue, because its one of the many symptoms of a bigger problem. 1). lack overall uniform guidelines that are followed 2). lack Customer first and usablity attitude, 3) lack of proper communication flow with the developer community.
all of which are some of the few things that are needed by a company to demostrate that they are an enterprise level company ready to deploy enterprise ready software.
don't get me wrong, i think highly of zend, but for this whole enterprise ready campaign is way beyond their current scope of abilities as long as their concept and standards of enterprise is much lower than what many developer s in this forum expects it to be as well as other developers in the world.
So if there are no improvements to object oriented structure of php, at the very least, a nice uniform version of php should be in order to build off of, esp with the IDE being built and the framework being built. small details add up to a bigger equation and sooner or later, it will catch up.
and if the developers would like more help, some decent c docmentation and some nice long articles on the structure of the code would be helpful.
but thats must my opinion
-
Dec 5, 2005, 14:29 #29
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Dr Livingston
I have never really understood the PHP library naming complaints. They seemed to orignally come from Java guys who could find little else to complain about and were disturbed by PHP's popularity.Christopher
-
Dec 5, 2005, 14:42 #30
- Join Date
- Aug 2003
- Location
- Toronto
- Posts
- 300
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by mx2k
Even still, mostly I just see nit-piks against the PHP Group (though I agree that some of them are quite deserved). I've seen many posts by people who either have no experiece at the enterprise level or whose expectations aren't in-line with actuality. PHP by no means represents a model of meeting enterpise-class requirements -- but in balance, I'd say it is meeting many of the pressing needs faced by enterprise developers and that in general, the situation is improving. There is plenty of room for improvement but at the same time, there is no reason to not let the foot in the door at this point.
By-the-By: I find it ironic that one can argue for enterprise-readiness on the one-hand but on-the-other-hand is willing to justify a hard BC break (changing function signatures) for the sake of "purity". By-and-large, every enterprise I've been at has prefered pragmatism (and low-cost) versus academic purity and (expensive) re-writes. In this day of "smart" modern IDE's, do we really care that much about minor details like that? Or more aptly (because I know we fundamentally "care") -- does it matter much?
-
Dec 5, 2005, 15:05 #31
Originally Posted by jayboots
whether opensource effort or not, zend does put out the core engine and has the most control over it. code whether open or not, is a product and any person who uses it, a customer. So what I have stated is fair from my p.o.v.
if i did project on source forge, despite that it may be os, its still a product and if i consider myself a professional, i would have an obligation to my customers, even though the product was free and the license stated otherwise.
-
Dec 5, 2005, 15:30 #32
- Join Date
- Jun 2003
- Location
- Iowa, USA
- Posts
- 3,749
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
http://tnx.nl/php#chaos
It begs the questions, how can the PHP global function namespace be such a mess, and yet PHP continues on a stong path of growth while Perl stagnates?
(not based on any facts, more of an anecdotal evidence from the fact that I read all PHP related forums)
Jason Sweat ZCE - jsweat_php@yahoo.com
Book: PHP Patterns
Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
Detestable (adjective): software that isn't testable.
-
Dec 5, 2005, 15:40 #33
- Join Date
- Aug 2003
- Location
- Toronto
- Posts
- 300
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by mx2k
Originally Posted by mx2k
Regards.
-
Dec 5, 2005, 17:51 #34
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by sweatje
-
Dec 6, 2005, 08:16 #35
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by sweatje
The easy availability of all sorts of functions in PHP is supremely convenient. In Perl you need to download a module from CPAN to do simple tasks like URL encoding or basic variable substitution. And object-orientation in Perl is interesting, but not elegant.Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
Dec 6, 2005, 12:26 #36
Originally Posted by dagfinn
Adding namespaces would provide an easy mechanism for dealing with this kind of situation, allowing the core function and class library to grow without any fear of breaking backwards compatibility, and making it much simpler to reuse and share code.
-
Dec 6, 2005, 12:57 #37
- Join Date
- Aug 2003
- Location
- Toronto
- Posts
- 300
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by 33degrees
I suspect this concept bothers a lot of OOP folks: why call a Person class a FooCo_Person when it is a Person?? Chances are more than likely, though, that someone else also thinks their Person class is the generic holy grail of Person classes and so will also grab "Person". You see where this is going; however, to be fair, there tends to be more expressed interdependancies in OOP code such that simple names are a bit of a plus in that situation.
-
Dec 6, 2005, 13:28 #38
Originally Posted by jayboots
you say that is bull picky, because that is your opinion/pov. I would say that a common person would look at it as a product more so than from a FOSS p.o.v, people see free and they go to grab, usually never understanding any underlining ideals, philosophies, or even licenses behind it. (hence we are past the MTV generation and are now a cut, paste, and click generation)
There are different ways of being compensated for work other than money. It really depends on your goals. A good reputation, becoming a part of history, fame, influencing the world around you, (which are a quite a bit of worth that sometimes you can't put a price tag on).
There are also other routes, offering a free product and charge for special add-ins or development equipment, to which zend does that to some degree.
But this has become a bunny trail. My point was that the PR (public relations) picture they are trying to paint is not quite balanced with their current methodologies. And i just threw some suggestions to which they could do to help live up to that PR hype.
a uniform code base would help move php towards Enterprise Integration, which is a part of the whole current stage of..."php is enterprise ready". But again that is a suggestion and my opinion.
-
Dec 6, 2005, 14:05 #39
- Join Date
- Aug 2003
- Location
- Toronto
- Posts
- 300
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Off Topic:
Originally Posted by mx2k
Greetings.
-
Dec 6, 2005, 20:16 #40
Originally Posted by jayboots
Originally Posted by jayboots
-
Dec 7, 2005, 02:11 #41
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by 33degrees
I've done that in the project I'm currently working on. The class names hover around 40 characters in length. If I want to type hint and keep the line length reasonable, I need one line per method argument.
My solution--which may or may not be the best one--is to groan in disgust and forget about type hinting altogether.Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
Dec 7, 2005, 11:34 #42
- Join Date
- Aug 2003
- Location
- Toronto
- Posts
- 300
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by dagfinn
FWIW, I try to follow the policy of only typehinting on interfaces or abstracts (if I am forgoing an interface) -- at any rate, generics. These tend to have much shorter names than concretes and help promote a reasonable level of re-use while still satisfying a minimal level of checking. If I find that I want to typehint a concrete I begin to think that my design is going astray since that would introduce harder dependancies.
Cheers.
-
Dec 7, 2005, 12:11 #43
- Join Date
- Sep 2004
- Location
- Zagreb, Croatia
- Posts
- 830
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
There is only one rule about type hinting you should conform to, and you will be fine: don't use it.
-
Dec 7, 2005, 12:36 #44
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
If I find that I want to typehint a concrete I begin to think that my design is going astray since that would introduce harder dependancies.
You should only be type hinting to interfaces anyways. Even type hinting to an abstraction is bad news in my view...
-
Dec 7, 2005, 12:37 #45
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
don't use it.
Why would your views be any different?
-
Dec 7, 2005, 14:13 #46don't use it.
-
Dec 7, 2005, 14:20 #47
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Umm...
Nope, I'm still not convinced that, that is an acceptable excuse or reason, as a lot of other languages throw fatals on those violations. The one exception with PHP is that you can't catch those violations, like you can with Java for example.
But in saying that, that is a fault with PHP - it doesn't support the functionality that Java has - but not with type hinting in it's self. Like, who is to say that in PHP6, that we won't have that same feature that Java has...
One can hope
-
Dec 7, 2005, 14:42 #48Nope, I'm still not convinced that, that is an acceptable excuse or reason, as a lot of other languages throw fatals on those violations. The one exception with PHP is that you can't catch those violations, like you can with Java for example.
But in saying that, that is a fault with PHP - it doesn't support the functionality that Java has - but not with type hinting in it's self. Like, who is to say that in PHP6, that we won't have that same feature that Java has...
-
Dec 7, 2005, 15:09 #49
- Join Date
- Sep 2004
- Location
- Zagreb, Croatia
- Posts
- 830
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Dr Livingston
And a question inspired by some of your posts above: what other languages besides PHP have type hinting? I'm not saying there are none, I'm just not aware of any. (Note: I'm talking about type hinting, not static typing. There's a huge difference.)
-
Dec 7, 2005, 15:12 #50
- Join Date
- Aug 2003
- Location
- Toronto
- Posts
- 300
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Dr Livingston
http://derickrethans.nl/erecoverable.php
Because it ads virtually no value to your code -- except some minor benefits that can equally well be implemented via in-code documentation -- while (sometimes severely) limiting your options.. Unfortunately, not using it at all means your code is subject to quite unintended uses that you might actually be better off protecting against.
Bookmarks