Hi, On Wed, Apr 21, 2010 at 3:20 AM, Stanislav Malyshev <s...@zend.com> wrote:
Come on. Is it really that hard to write strlen? Or array_merge? Would it be > better if they were len (of what?) and merge (what?)? I don't think so. I think you missed the point when I said we should use system namespaces. There are several ways in which to use namespaces, including aliasing. > > procedural-style PHP. But now we have namespaces, that were introduced >> exactly for this kind of situations. Why not take advantage of it? PHP can >> > > Nope. The namespaces were introduced to manage deep and wide class > hierarchies, especially large frameworks with hundreds of classes, not to > bother little string functions that never hurt anyone. > > You know, there is a world out there too, outside the "deep and wide class hierarchies". I really doubt that namespaces were introduced in the language with the sole purpose of grouping hundreds of classes. But you can, if you make everything a class. > > > 2. TYPE HINTING. Currently PHP supports argument type hinting for arrays >> and >> objects. As I know, it's also been decided to offer support for this in >> function return values. For me it is hard to understand why not offer >> > > Decided by whom? When? > > Here http://www.php.net/~derick/meeting-notes.html#type-hinted-properties-and-return-values. But this may be outdated, sorry if I may not know well. > > code coincides with the global namespace ( \ ) code, I think it's safe to >> remove the *define* function and possibly allow the *const *keyword to >> define runtime constants as well (when the value is not a constant >> expression). >> > > That would not work since code can not be run when class is being parsed, > and after that it is not clear when it is supposed to be run and in what > context, etc. But more importantly - what for? If you need to calculate > something, make it a variable and calculate it in the ctor. Constants aren't > meant to be results of complex calculations, they are meant to be simple and > fixed. > There was a proposal for read-only variables and one for per-variable > getters/setters (actually, with some effort you can do it right now, a bit > less efficiently maybe but doable). This might be direction to go in this > case. > > When I said global namespace, I meant outside any class as well, where we would normally use *define*. My focus was that constants are not meant to be nor simple, nor complex, but just... constant. I cannot use a variable computed in the ctor or anywhere else, because that would not be constant. Simulating readonly properties with a combination of private access and a magic getter is probably a good example of bad code. > > 4. PARAMETER ORDER. As noted in an older PHP meeting: >> > > Two letters: BC. > Changing variable order in an existing function is a big fat BC break. And > if we put such a bomb into a new version, what would be the incentive for > people to use it? So that apps would have to be shipped in 2 versions, for > the old php and the new php? > > What you call a bomb, I call a fix in the language. People should use it because it is better, not because it is "more". Current apps are shipped in two versions, for both PHP 4 and 5? No. Take a look at Python 3 for another example. In the long run, it's more acceptable to break some code once with a new feature (and devs will know why and what to fix), than have the code break itself over the time due to bad design. > > Please remember - what you call "ancient code" other people call > "application on which my paycheck depends". So I think we should be > super-extra-careful when messing with it. That doesn't mean we would never > do any BC-breaking change ever - that does mean there always has to be a > very good reason for it. And I personally don't see "consistency" being good > enough reason. Don't get me wrong - it's good, it's just not good enough to > be valued over working applications. > I totally agree with the phrase "application on which my paycheck depends". But applications are developed, fixed and maintained, they are not static, nor statues that we stare at. I cannot agree with the idea of preferring working applications to good working applications. Our main focus here is the language and developers' main focus is their applications. So, indeed, my opinion is that PHP should take several design decisions in the future even though some are bolder than others, because I believe applications will benefit from this in the long term. I don't refer to the proposals above, but to any solid change that deserves a chance. With breaking code in mind, we'll have only things added up and end up with a much bigger and only slightly better PHP.
