Re: [PHP-DEV] Namespace issues
On Mon, 20 Oct 2008, Philipp Wagner wrote: Steph Fox wrote: Hi Lester, And there are no problems with those on foreign keyboards? If there are, those foreign keyboards are unable to offer either escaped chars or MS paths... which seems highly unlikely. Well, on German keyboards, it's accessible but only by using ALTGR+?, which is not really a comfortable combination. So in your editor, map ::: to \ and be done with it no big deal. regards, Derick -- HEAD before 5_3!: http://tinyurl.com/6d2esb http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace issues
Hi,
Guys, this is like junior school in here.
Let me put some things in perspective:
1) The location of backslash on foreign keyboard is entirely irrelevant for
the choice of namespace separator. Why? You already use this *every day* to
escape characters in your strings and regular expressions. Anyone complained
about the location of backslashes in there? No.
2) Where the backslash is, is also where the {} and [] are on those
kayboards, as some people already said.
3) Backslash is ugly -- are you honest? Which is uglier::::Foo()
::Foo() or \Foo(); The last one at least has intuitive meaning (like file
paths: absolute path). Face it that you'll be typing either one of the above
three a *lot*, and pick one that makes sense visually and for newcomers
alike. I think that's the backslash.
4) But we want the same operator. Well? I want a pony, the fact is
however, the other languages have the design to afford the same separator
for namespaces, static methods and members. Shoehorning this in PHP while
maintaing BC will create such nightmares in big projects with ambigous
identifiers, autoload performance issues, that you'd wish you go back and
change the damn namespace operator to just about *anything* but ::.
I wish the people who have a clear opinion of the above voice their opinion.
For those who aren't quite sure what the issues in point 4 are, please just
stay low and follow the list until you do.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace issues
The N word discussion looks neverending...
solution #3 from Gregory solves the ambiguity so I dont see how it will
create such nightmares in big projects with ambigous identifiers. I'm
using the :: operator for the last 6 months and I had no such issues even
without the fix (I'm not naming classes and namespaces in the same way, and
I dont see why I would need to do so). Have you tried using it?
If the __autoload performance problem is solved I dont see what is the
problem with the current separator. I would wait for the opinion of Gregory
and Stas Malyshev on this matter.
On the other hand I dont think the backslash is ugly, and I think that the
windows users will find it somewhat familiar for using it in tree structures
like the namespaces.
On Tue, Oct 21, 2008 at 10:33 AM, Stan Vassilev | FM
[EMAIL PROTECTED]wrote:
Hi,
Guys, this is like junior school in here.
Let me put some things in perspective:
1) The location of backslash on foreign keyboard is entirely irrelevant for
the choice of namespace separator. Why? You already use this *every day* to
escape characters in your strings and regular expressions. Anyone complained
about the location of backslashes in there? No.
2) Where the backslash is, is also where the {} and [] are on those
kayboards, as some people already said.
3) Backslash is ugly -- are you honest? Which is uglier::::Foo()
::Foo() or \Foo(); The last one at least has intuitive meaning (like file
paths: absolute path). Face it that you'll be typing either one of the above
three a *lot*, and pick one that makes sense visually and for newcomers
alike. I think that's the backslash.
4) But we want the same operator. Well? I want a pony, the fact is
however, the other languages have the design to afford the same separator
for namespaces, static methods and members. Shoehorning this in PHP while
maintaing BC will create such nightmares in big projects with ambigous
identifiers, autoload performance issues, that you'd wish you go back and
change the damn namespace operator to just about *anything* but ::.
I wish the people who have a clear opinion of the above voice their
opinion. For those who aren't quite sure what the issues in point 4 are,
please just stay low and follow the list until you do.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Vesselin Kenashkov
developer at
www.webstudiobulgaria.com
Re: [PHP-DEV] Namespace issues
2008/10/21 Stan Vassilev | FM [EMAIL PROTECTED]
Hi,
Guys, this is like junior school in here.
Let me put some things in perspective:
1) The location of backslash on foreign keyboard is entirely irrelevant for
the choice of namespace separator. Why? You already use this *every day* to
escape characters in your strings and regular expressions. Anyone complained
about the location of backslashes in there? No.
2) Where the backslash is, is also where the {} and [] are on those
kayboards, as some people already said.
3) Backslash is ugly -- are you honest? Which is uglier::::Foo()
::Foo() or \Foo(); The last one at least has intuitive meaning (like file
paths: absolute path). Face it that you'll be typing either one of the above
three a *lot*, and pick one that makes sense visually and for newcomers
alike. I think that's the backslash.
4) But we want the same operator. Well? I want a pony, the fact is
however, the other languages have the design to afford the same separator
for namespaces, static methods and members. Shoehorning this in PHP while
maintaing BC will create such nightmares in big projects with ambigous
identifiers, autoload performance issues, that you'd wish you go back and
change the damn namespace operator to just about *anything* but ::.
I wish the people who have a clear opinion of the above voice their
opinion. For those who aren't quite sure what the issues in point 4 are,
please just stay low and follow the list until you do.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Exactly my feeling. When it comes to dealings with 15+ MB codes (after
excluding all 3-rd parity libraries), ambiguity problem becomes real even
now. It's hard enough to think of good name for 2 similar, but different in
realisation modules, so that you understand what they are for and to
understand what is different between them. I deal with 3 projects 50 MB +-
in size every day, jumping from one to other sometimes few times a day. such
projects 100% have large amount of variables named equaly. If you begin to
implement namespace support and access them outside namespaces, it becomes a
nightmare to understand what it accessed.
I see two solutions:
1). Change the separator.
2). Don't allow function, class, constant and variable naming same as
namespace name. Make it a fatal error. Then this will be solved.
Other options like throwing something away or make an ambigity resolution
mechanism personaly me don't make happy. Throwing something away leaves us
with something half working. Ambigity resolution mechanism makes us to
remember what is what (scrolling up and down tens of times a day is realy
disturbing the work), but is for sure better than first one.
If we combine all good things from all proposals, we can get one big solid
thing. Just my IMHO, but still:
1). Change the separator.
2). Make resolution to global classes, functions, constants first and if not
found - then to namespace. But realy, may be use self to point to namespaced
function, class, method ? Same as $this in classes. That seems logical,
because PHP is already using such mechanism.
3). Don't allow ambigity naming. Die with E_FATAL in such cases, don't allow
thouse coders to write bad code, please do! I beg you!
I don't know how parser works exactly, but maybe constant ambigity could be
resolved by patch, witch resolves constant values at compile time. If that
can't be done, than issue E_FATAL.
Just my IMHO. Please, don't make a holly war of my post. I wount argue with
holly war responces. Just tell me where I'm wrong and if that's because of
implementation difficulties - explain, I will understand that techno bable
:)
Re: [PHP-DEV] Namespace issues
Hi, Guys, this is like junior school in here. Yep. Let me put some things in perspective: No, let me. Greg worked his butt off the entire weekend looking for the flaws in *all* the options available to us, including a couple of new ones that never even reached the list before he rejected them on technical grounds. Thanks to his efforts, we already have a pretty good picture of the strengths and weaknesses of each approach - and as should be obvious to all by now, there is no perfect solution. Whatever we chose, it's a compromise. What we're hearing here about European keyboard layouts is useful info because it gives some idea of how popular/unpopular the backslash would be as a solution and why, but it shouldn't carry as much weight as the accessibility argument against the triple colon. One is liveable, if not optimal, whereas the other is plainly not liveable for some. We've already heard two workarounds for the backslash issues, but there are none at all for ::: + imperfect eyesight. Clarity and simplicity are the two chief requisites. We're all fully aware of that, from Engine developer to n00b, so there's really no point in discussing it to death on-list at this stage. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Namespace issues
Clarity and simplicity are the two chief requisites. We're all fully aware of that, from Engine developer to n00b, so there's really no point in discussing it to death on-list at this stage. Yep. I agree. I'm already tired of watching this thread. Let them agree on an implementation that is going to work with THE LEAST AMOUNT of cons. - because some of us (that means me) really just want namespaces implemented, and for one reason it doesn't really count what 'sign' it's used to mark a namespace, as much as the functionality they bring. As long as my PHP job depends on developing extremelly simple methods/functions for our noobish PHP developers, namespaces are a great functionality needed to map 'same-name functions/methods' to a freakin' namespace that would be simple to use for the average PHP developer. So, my Nike-borrowed motto is: Just do it (already!) ... ... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace issues
Steph Fox wrote: What we're hearing here about European keyboard layouts is useful info because it gives some idea of how popular/unpopular the backslash would be as a solution and why, but it shouldn't carry as much weight as the accessibility argument against the triple colon. One is liveable, if not optimal, whereas the other is plainly not liveable for some. We've already heard two workarounds for the backslash issues, but there are none at all for ::: + imperfect eyesight. I should probably apologise for bringing up the keyboard question, but I did so purely because a number of people had mentioned the problem. I was just trying to refer to the general problem that while many of the symbols used are on US keyboards, they may well be used for local characters on other layouts, and can be difficult to access for some developers. I was just trying to flag a general problem that is often ignored rather than the specific /::: one. Clarity and simplicity are the two chief requisites. We're all fully aware of that, from Engine developer to n00b, so there's really no point in discussing it to death on-list at this stage. Have we reached a consensus? Or is this still a little open ended? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace issues
Steph Fox wrote: Have we reached a consensus? Or is this still a little open ended? Scott's trying to pull together a developer-only meeting so we can look at what's left in a bit more depth. Once we've done this it'll probably come back to the list (should, IMHO). Timezones, timezones! Don't start another long debate ;) Pigging time offset in browser is useless for determining timezone/DSL :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] str_getcsv
The main branch? PHP_5_X are the stable branches, HEAD is the development branch (at least in theory ...) So stuff is added to HEAD and merged bacxk when it's stable enough and need (and somebody cares) +1 from me, though... johannes Now, if we could work the phrase namespaces into this somehow we'd probably have this in HEAD within a few days. On a serious note, there seem to have been quite a few commits to MAIN over time, so I wonder what else is lurking there that could be useful? If nobody else is doing this then I'm happy to build a diff, What's involved in getting a commit account for CVS or is it easier to just email a diff set to somebody (in which case, who?) Steve The information contained in this email is intended for the personal and confidential use of the addressee only. It may also be privileged information. If you are not the intended recipient then you are hereby notified that you have received this document in error and that any review, distribution or copying of this document is strictly prohibited. If you have received this communication in error, please notify Brendata immediately on: +44 (0)1268 466100, or email '[EMAIL PROTECTED]' Brendata (UK) Ltd Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX UK Registered Office as above. Registered in England No. 2764339 See our current vacancies at www.brendata.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] str_getcsv
hi, On Tue, Oct 21, 2008 at 7:32 PM, Steve Hanselman [EMAIL PROTECTED] wrote: The main branch? PHP_5_X are the stable branches, HEAD is the development branch (at least in theory ...) So stuff is added to HEAD and merged bacxk when it's stable enough and need (and somebody cares) +1 from me, though... johannes Now, if we could work the phrase namespaces into this somehow we'd probably have this in HEAD within a few days. On a serious note, there seem to have been quite a few commits to MAIN over time, so I wonder what else is lurking there that could be useful? If nobody else is doing this then I'm happy to build a diff, What's involved in getting a commit account for CVS or is it easier to just email a diff set to somebody (in which case, who?) Easiest (and safest) is: - to create a patch (cvs diff -up) - open a feature request (a bug :) in bugs.php.net, with a link to the patch - post it in this thread as well with a ref to the bug # Doing so will make sure that your patch will not be lost in the archive :) After having provided a couple of patches, you may consider a CVS account request. Thanks for your work! Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Destructor Order
I've been wondering, is such a thing even possible? Is there a good way to implement an object destruct order? Here are my thoughts: In the class definition, specify what level of destruction the objects should be on. How, I have no idea, I haven't thought of a good syntax. It should be an integer for what level though. Then when the script ends, the engine starts with the highest most level of destruction. It continues down until everything has been destructed. With the last most level being objects with unspecified levels. Note: Each level can have more than one class. Example destruction order: 3 = database records (ActiveRecord or such) 2 = database connection object 1 = framework objects 0 = objects with unspecified level -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
